Hello, Am Montag, 10. August 2020, 12:22:50 CEST schrieb Lubos Kocman: [...]
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.
Let me play devil's advocate, and also warn you that the following paragraph might contain traces of sarcasm ;-) In the good [1] old times ;-) of FATE (aka features.o.o), _everybody_ was able to submit a feature request and to see feature requests by community members. And now you are telling us that we should be thankful that 10 selected people will get access, and maybe that number will increase? Of course, 10 is better than nobody, but IMHO the perfect number of people allowed to access Jira would be ∞ ;-) Allowing everybody to access JIRA could have benefits for both SUSE and the community. For example, with more people having access, maybe someone would accidently stumble over a feature request, and help to implement it? Or someone comes up with an idea for _the_ feature that would generate lots of money for SUSE, but doesn't want to do the paperwork to get access to JIRA? I also have a question: which feature requests will the selected openSUSE contributors be able to see? Those reported by other openSUSE contributors (would be similar to FATE/features.o.o), or also feature requests reported by other partners? (You can probably guess my prefered answer, but I also understand that other partners might want to have their requests kept private.)
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/im ages/svg/openSUSE-jump-content-workflow.svg (also available in drawio and png).
That flow chart has good chances to cause headache ;-) but luckily you also provided a text summary, which looks mostly good. BTW: I'd s/Mait. project/Maint. project/ at several places in the flow chart. [...]
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.
So technically Leap will be (with very few exceptions, like branding) equal to SLE + Package Hub?
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.
Right, this transparency is indeed a big improvement, and much better than having to manually check if the updated (in my case typically AppArmor) package has already reached the Leap repo.
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.
That sounds like additional paperwork. Is this really needed for each and every SR that goes towards SLE? Disclaimer: I've seen a "nice" example of that paperwork with a somewhat late AppArmor submission for 15.2 and might therefore be overly sensitive. I have no idea if this was "typical" paperwork or if I just had bad luck ;-) OTOH, earlier submissions didn't need such paperwork - or the SLE maintainer did all the paperwork without telling me.
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
Devil's advocate again: Duplicate index '1' ;-) [...]
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.
Two questions: - in your example, what would be the correct target of the SR? - can't that be automagically handled via OBS redirects? Regards, Christian Boltz [1] I won't claim that FATE or features.o.o were perfect, but at least when it came to having access, I had no reason to complain. Oh, and even if the signature is also about the "good old times", it was randomly selected by fortune. However, it isn't the first time I start to wonder if someone added some AI to fortune's "random" selection ;-) -- Früher als ich noch alles mit vi auf der Kommandozeile gemacht und X11 nur im Notfall und dann auch nur mit fvwm2 gestartet habe (Modelines selbstredend noch zu Fuß errechnet nicht mit so Warmduscher-Tools wie SaX) da wusste ich jederzeit dass ich ein Mann bin. Das ehrfürchtige Staunen von minderbemittelnden Windows-Usern, die zufällig Zeuge meiner rituellen Arbeit wurden war mir sicher. Heute fragen die nur noch wo ich die schöne Icons her hab. Scheiße ... [Hartmut Meyer in suse-linux] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org