Hello openSUSE! I do have some exciting news to share! TLDR: openSUSE Jump builds will be now publicly available, jira.suse.com access for contributors in 5 weeks, OBS submissions against SLE packages will be submitted against Jump and mirrored in IBS. Any updates on request will be then synced outside (bi-directional sync). Proposed workflow received thumbs up from Maintenance and SLE Release Management. https://github.com/openSUSE/CommunitySLEFeatureRequests/blob/master/images/s... First, I'd like to announce that we'll start publishing images and FTP trees for openSUSE Jump*, so people can get their hands on. Please be aware that Jump is still in Alpha quality. I expect data to be available later this week as there is still pending work on pontifex by Heroes. https://build.opensuse.org/project/show/openSUSE:Jump:15.2 Second, I've agreed on ETA of 5 weeks for the initial availability of JIRA partner access to openSUSE Contributors (JIRA-722). In this way, we can have transparent handling of feature requests, just like for any other SUSE partner. I hope that this brings some more transparency and self-service for SLE -> openSUSE feature requests. TAM for openSUSE (Lubos) will be in charge of controlling the access. We'll initially have rather a smaller pool of users (initially 10) and will grow it over time based on the popularity. Just FYI: The standard size of the pool for partners is 2, so openSUSE is being taken seriously as a partner here. Second, the proposal of the new submission model for the openSUSE Jump and it's SUSE Linux Enterprise part was accepted well by the Maintenance team and SLE Release management, therefore **I'd like to hear your opinion**. My hard requirement is that we will NOT reject submissions just because it's a submission against an SLE package. My attept to capture is here https://github.com/openSUSE/CommunitySLEFeatureRequests/blob/master/images/s... (also available in drawio and png). Log story short, an openSUSE contributor would always submit code against a single project. Let's say openSUSE:Jump:15.2 for now (later Leap). Code submission would then get redirected to a proper origin (Backports, Leap, SLE). The tool for SR redirection is already in place (OBS-59). Origin options: openSUSE Backports (for the majority of Leap packages ~8k), openSUSE Leap (mostly branding packages, patterns, and SLE package forks of packages necessary to keep openSUSE Leap building ~100) SUSE Linux Enterprise (~4k packages, the core) Backports and openSUSE Leap code submissions will have pretty much the same experience as now. With the exception that you'll be able to use just one submit request target for more convenience and reusability as there will be one build used for both Package Hub and Leap. Submissions to SUSE Linux Enterprise will get more transparent. I'd really like to ask you to look at it as a good starting point. I see it as a big improvement from what we have now since you'll be now able to see behind the scenes. This all is constantly happening, you were just not able to see it before. This would be more or less a regular way to update an SLE package. 0) The contributor reports a bug or logs in to jira.suse.com and files a partner feature request for new features. JIRA request can still be created by TAM (Lubos) if there would be any problem (e.g. missing access etc). User (and other openSUSE contributors who requested JIRA access) see updates in JIRA. 1) TAM reviews feature and reject with reasoning or gives it a go and passes it for further evaluation. 1) The contributor submits code against openSUSE:Jump:15.2 (later Leap), optionally references openSUSE Partner JIRA feature (see my note on JIRA access) or a bug 2) openSUSE Release team reviews a new type of review let's refer to it as an "openSUSE Jump" review for now. 3) Approved submissions will get mirrored (OBS-63) from OBS to IBS (Internal SUSE OBS instance) with bi-directional sync on comments, updates for full transparency so the contributor can see progress on the submission by himself. 4) Submission gets processed by SLE Release Management or Maintenance team based on the origin (see my note below). At this point, it's either rejected or passed on staging for pre- integration tests. Reject reasons might be not following (not a full list) Failed code review such as skipping Factory First, mandatory 4 eyes review, etc. Change is past the code-submission deadline Missing approval on a feature, ECO or a missing issue reference Does not meet usual maintenance update criteria such as backward- incompatible update or would require a rebuild of a lot of packages Failed pre-integration testing. The reject reason would be communicated in the submission. Generally, the submission criteria would be the same as any SUSE employee. 5) openSUSE TAM (Lubos) optionally creates an ECO* to get approvals for feature requests in a late development phase or Maintenance updates. 6) Mirrored SR in IBS and Original SR (via bi-directional sync) gets accepted (or rejected). 7) The partner feature request is marked as Done or bug is marked as Resolved. Just one note on SLE Submit requests, which I believe will be a source of many conflicts. Submissions to SUSE Linux Enterprise* are a bit more tricky due to the project inheritance, as packages are coming from older SLE Service Packs, respective its ":Update" projects. That means that it won't be uncommon that the user will be submitting code against for an example openSUSE Leap 15.3 during the Early Alpha phase, however, in the end, it's going to be a submission for SUSE:SLE- 15-SP1:Update. Such submission may require additional ECO* approval or will result in a fork in the latest Service Pack of SLE. So I recommend all users to use "osc origin" to check where does the package come from, to avoid any surprises later on. And the last I'll check our wiki pages and make sure that the content is in alignment with the presented idea. https://en.opensuse.org/openSUSE:Submitting_feature_requests) https://en.opensuse.org/Portal:Leap/SLEFeatureRequests https://github.com/openSUSE/CommunitySLEFeatureRequests/ So what do you think? [0] openSUSE Jump https://en.opensuse.org/Portal:Leap:Jump [1] ECO - https://en.opensuse.org/ECO [2] The submit request will be mirrored in OBS under a different ID etc. but the state of original submission will be Accepted. [3] IBS - SUSE Internal OBS instance, that is used to build SUSE Linux Enterprise Thank you for your time