Hi Luboši, Lubos Kocman <lubos.kocman@suse.com> writes:
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).
This sounds good to me.
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.
You mentioned further above that there will be only 10 users available for now on jira.suse.com. What would the those who are not SUSE employees and who are not part of these 10 selected individuals do? File bugs in Bugzilla? If that is the way, then what should they do for packages that have no bugowners?
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.
So TAM can effectively block any requests?
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?
Overall I think this will be an improvement over the current situation. What I don't really see addressed here though is how packages are handled that are maintained by different people in openSUSE and in SLE, if the openSUSE maintainer does not work for SUSE. I have been told that such a state can be very frustrating for the maintainer in openSUSE (this is hearsay, I have not experienced this situation myself) as the SLE maintainer can effectively dictate a lot. Are there any plans how this process could be made less painful so that contributors will not actively try prevent their packages landing in SLE? Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer