[opensuse-factory] How to get stuff to the new Leap prototype?
Hello openSUSE! let me share a proposal on how could the new submission workflow for the "Jump" could look like. Just to make sure, Jump is the openSUSE Leap prototype build on top of SLE Binaries and Backports. FYI: Tasks for current Jump effort are tracked here: https://progress.opensuse.org/projects/jump_152/ **Let's define 4 separate package origins:** (1) **SUSE:SLE-15* Code stream in OBS** * Synced 1:1 from IBS with few packages skipped, 00products, 000release-packages, packages related to infrastructure, live patching, ... less than 50) *Roughly 4000 packages (2) **Backports** * Additional packages for Leap and SLE via https://packagehub.suse.com/ . Available by default to Leap user, SLE user has to enable Package Hub. * Roughly 8000 packages (3) **openSUSE Leap forks of SLE packages** * Packages with additional functionality that didn't make it to SLES. This should be a very small group of packages (<130). * Less than 130 packages (4) **openSUSE Leap distribution and branding** * Packages defining content of openSUSE Leap artifacts (000products, release packages, kiwi descriptions) and *-branding packages * Less than 50 packages So here are my thoughts ... Updating the base system There is currently no well-defined process for updating (1) aside from the Factory First rule. Not many SLE packages are in sync with the version from Factory, so that rule just by itself is not sufficient. This is 1/3 of the openSUSE Leap distribution. Changes are usually handled via bugs in openSUSE product. Release Manager transforms Submit Requests or Bugs during review into SUSE Linux Enterprise feature requests. I usually try to handle this while Bugzilla triage, which is setting priority to bugs with priority set to P5 (None). A feature gets approved, or bug gets resolved. Change is implemented in IBS, synced to OBS, Jump gets the new build. This takes quite some time. And lowers the turnover rate of Rel-eng. I did a small research and contacted all Bugzilla component owners in openSUSE Distribution. Most of the feedback was that it is the team's best effort to triage bugs. Bugzilla should be used only for bugs, not a feature request, which is currently the case. This is a candidate for a brand new process that should be available to all active openSUSE Leap contributors. I can imagine a similar process to an existing SUSE partner feature request process in jira.suse.com. I did already create a request for our Jira team. At this point, it's still unclear where and how will be the request tracked. We'd like to have this implemented by Q3/2020. Updating openSUSE Leap package which is not in SLE Changes to (2) would be the same as today, in case that "Jump" is just a parallel build. This means submission to openSUSE Leap 15.2. From a Jump "as the only Leap" perspective. Submit Request is newly created against the openSUSE Backports project in OBS. openSUSE Backports don't have a Staging process to my knowledge, this needs improvement. Integration testing is necessary. Otherwise, I like this, since here it reduces work. One less SR and one less build mean less waiting to get the change in. The workaround to resolve blocking issues similar to SLE Workarounds would be still available if we need it. Submit to openSUSE Backports was happening anyway, to provide software to SLED/SLES. We can now even distribute the very same binary for SLE and Leap. Changing the distribution This would be the case for any package in (4). A direct Submit Request against the existing package in "Jump". Usually done by a member from the openSUSE Rel-eng team. Moving apart SLE and openSUSE Leap Commits to (3) should be subject to extensive review. We should always try to approach it in the same way as a Feature request in (1). Try to get SLE buy-in and extend fork only if necessary. Generally, the attempt here is to reduce this group and therefore have equal functionality in SLE and Leap if possible. What do you think? -- Best regards Luboš Kocman Release Manager openSUSE Leap SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer
On 4/14/20 6:47 PM, Lubos Kocman wrote:
Hello openSUSE!
let me share a proposal on how could the new submission workflow for the "Jump" could look like. Just to make sure, Jump is the openSUSE Leap prototype build on top of SLE Binaries and Backports.
FYI: Tasks for current Jump effort are tracked here: https://progress.opensuse.org/projects/jump_152/
**Let's define 4 separate package origins:**
(1) **SUSE:SLE-15* Code stream in OBS** * Synced 1:1 from IBS with few packages skipped, 00products, 000release-packages, packages related to infrastructure, live patching, ... less than 50) *Roughly 4000 packages
So here are my thoughts ...
Updating the base system
There is currently no well-defined process for updating (1) aside from the Factory First rule. Not many SLE packages are in sync with the version from Factory, so that rule just by itself is not sufficient.
This is 1/3 of the openSUSE Leap distribution. Changes are usually handled via bugs in openSUSE product. Release Manager transforms Submit Requests or Bugs during review into SUSE Linux Enterprise feature requests. I usually try to handle this while Bugzilla triage, which is setting priority to bugs with priority set to P5 (None).
A feature gets approved, or bug gets resolved. Change is implemented in IBS, synced to OBS, Jump gets the new build. This takes quite some time. And lowers the turnover rate of Rel-eng.
I think it would be good to try and involve package maintainers at a really early stage, especially in cases where there is a good working relationship but even in more general cases. For example last week someone from the community submitted something into leap that I already had pending in SLE, where a quick email first could have saved themselves and a bunch of others such as reviewers a bit of time. I'm not sure of the best way to word this but if bug reports generally created first as long as the SUSE maintainer gets cc'd so they can add input if they have it its probably ok. Cheers -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On Tuesday, 14 April 2020 11.17.52 CEST Lubos Kocman wrote:
[?] Bugzilla should be used only for bugs, not a feature request, which is currently the case. This is a candidate for a brand new process that should be available to all active openSUSE Leap contributors. I can imagine a similar process to an existing SUSE partner feature request process in jira.suse.com. I did already create a request for our Jira team. At this point, it's still unclear where and how will be the request tracked. We'd like to have this implemented by Q3/2020.
I don't think it's a good idea to use a SUSE platform (suse.com) for openSUSE feature requests. IMHO something with "opensuse.org" should be a good baseline. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (3)
-
Lubos Kocman
-
Oliver Kurz
-
Simon Lees