If you did not migrate your account yet, visit https://idp-portal-info.suse.com/
- 1 Who is the audience?
- 2 How to request access to jira.suse.com?
- 3 How to request a new feature?
- 4 Weekly reviews of open features
- 5 Is this a new thing?
- 6 Typical cases of SLE Feature requests
- 7 What about regular bugs?
- 8 How do I find package origin?
- 9 How can I create an SLE Feature Request?
- 10 What does "Change has to come from SLE" mean?
- 11 Current content workflow for openSUSE Leap including SLE Feature requests
- 12 Proposed content workflow for Jump
Who is the audience?
Both community and SUSE-internal contributors to openSUSE Leap who somehow need a change in one of packages which comes from SUSE Linux Enterprise (SLE). Companies which would like to partner with openSUSE. And are looking for a way to steer direction of openSUSE Leap. Please see an effort to capture these personas. openSUSE Leap contains roughly 4000 such packages with SLE origin as of today.
openSUSE Release team is here to help you in this regard.
How to request access to jira.suse.com?
At this very moment, access to the pilot is given only to active contributors who have submissions to openSUSE Leap.
Otherwise, please create your account at https://idp-portal.suse.com/univention/self-service/#page=createaccount
Next step is an explicit approval to have an access to the openSUSE partner project in SUSE's jira. This is maintained by openSUSE Release Manager (lubos.kocman AT suse.com).
How to request a new feature?
Weekly reviews of open features
Meeting takes place at https://meet.opensuse.org/FeatureRequests every Monday 2:00 UTC / 3:00 CEST openSUSE Leap Release Manager will review currently opened community features with screen sharing on. Our meeting minutes are tracked in https://etherpad.opensuse.org/p/FeatureReview-meeting
Is this a new thing?
This is not new to openSUSE Leap. It has always been the case. We're just getting it formalizCommunitySLEChangeRequestsed with the goal of making it easier and smoother over time. This is independent from Closing the Leap Gap proposal or the Jump prototype for a next release of openSUSE Leap.
Typical cases of SLE Feature requests
What about regular bugs?
Regular bugs are not in the scope of this process.
Please follow openSUSE:Submitting_bug_reports on how to submit a bug report. We'll be more than happy if you'll link the Factory submit request to the bug.
In most cases the final Submit Request (SR) will come from the SLE side and will then supersede any open openSUSE Leap SR against the package. Please keep this in mind.
How do I find package origin?
Use osc meta (example below) to check where the package comes from. Packages which are subject to this process are those with origin SUSE:SLE*.
Please note that SUSE Linux Enterprise uses a tree project structure where updates from previous service packs are inherited into newer service packs. openSUSE Leap 15.3+ inherits sources and rpms from the very same structure which is mirrored in the public Open Build Service.
SUSE:SLE-15:GA -> SUSE:SLE-15:Updates -> SUSE:SLE-15-SP1:GA -> SUSE:SLE-15-SP1:Updates -> SUSE:SLE-15-SP2:GA ...
Finding the origin of package for both sources and binaries:
linux:~> osc meta pkg openSUSE:Leap:15.3 python | head -1 <package name="python" project="SUSE:SLE-15:Update">
SLE vs Leap/Backports origin
linux:~> osc meta pkg openSUSE:Leap:15.3 python | egrep "openSUSE:Backports|openSUSE:Leap" && echo "Origin in Backports or Leap 15.3" || echo "SLE origin" SLE origin
linux:~> osc origin -p openSUSE:Leap:15.2 package kdelibs4 # Origin is Leap updates openSUSE:Leap:15.1:Update
How can I create an SLE Feature Request?
- Create a Submit Request against openSUSE Leap.
First of all please keep in mind that we all need to respect openSUSE:Factory_development_model, so make sure that it was submitted to Factory as well. This also contributes to having the feature request processed more quickly.
The Release Manager(s) and Release Engineer(s) will process the request and create an SLE Feature requests in JIRA and request approvals. Submit Request will be linked to the feature request.
Having an SR available significantly speeds up the process even though the SR against openSUSE Leap is expected to be rejected in the end as the change comes via SLE.
- Create a bug report against openSUSE Distribution.
The Release Manager(s) process all bugs with no priority set (default P5 priority) and transform obvious Feature requests into SLE feature requests in JIRA.
If applicable you can reference a Submit Request against Factory or even a rejected Submit Request against openSUSE Leap. Please be aware that requests should respect the criteria for upcoming milestone. For example, if you submit a brand new feature request in RC or post-RC phase it will be most likely rejected or deferred to a next release.
- Reach out to openSUSE:Release_team on irc
Preferably Release Manager for openSUSE Leap on irc / #opensuse-factory for more guidance. Do not use simply file request via plain email.
What does "Change has to come from SLE" mean?
The current openSUSE Leap workflow receives an automatic submission from SUSE Linux Enterprise as soon as it's accepted in SLE.
The Portal:Leap:Jump workflow will simply sync the SLE binary containing the change as soon as it is built.
Current content workflow for openSUSE Leap including SLE Feature requests
Following diagram covers current situation and highlights problematic part of packages with SLE Origin, see red boxes and arrows.
Latest source for the diagram can be found 
Proposed content workflow for Jump
Respectively proposed content workflow for new openSUSE Leap
Latest source for the diagram can be found