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