On 8/18/20 6:19 AM, Christian Boltz wrote:
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 ;-)
Let me maybe play devil's advocate back.
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 ∞ ;-)
I think the problem here was more while everyone could create a feature request, no one was reading them let alone thinking about implementing them, atleast now they are going into a tool where someone will probably look at them, let the maintainer know about them and maybe provide some feedback.
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?
It would have benefits, but I'm not sure they outweigh the excessive costs that would be required to purchase a license that would allow every member of the community simultaneous access. I guess when the product management team were considering the tool they wanted to use they didn't consider needing that number of licenses and considered a bunch of features jira provides over the competition as really important.
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.)
My guess is GDPR will mean that only the later, and its reasonable to expect that some others are under NDA so certainly not all.
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?
Package hub could end up linked to the version in tumbleweed, the leap maintainer could choose to keep an older version, ie not upgrade to the next major version until the next major Leap release, for example fish shell version 3 breaks alot of config so I decided its not suitable for inclusion in a minor leap version (but I created a fish3 package for people who want it) in this case I informed the package hub team and package hub has both, but that might not always be the case.
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.
As you mention here if the SLE package maintainers are aware of the request and can easily justify it for SLE and would like to see it included i'm sure we will try and find the way of including it with the least amount of paperwork (atleast I don't like doing unnecessary paperowrk)
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?
To make this easier, here's a practical real life example, as far as I can see dbus-1 has updated versions for SLE-12-SP3, SLE-12-SP5 and SLE-15-SP1 but not SLE-12-SP4 or SLE-15-SP2. I don't create a new version of the package for each release because then there would be more places where i'd have to backport security features, this costs time and money. Right now if I need to fix a security issue for dbus-1 by just updating the SLE-15-SP1 package I can fix it in SLE-15-SP1, 15-SP2 and 15-SP3, While because 15-GA-LTSS is a separate package id have to fix that manually. Now if you have a new dbus-1 "feature" for leap 15.3, I have two slightly different choices A. if it seems like it fixes an issue I can probably convince the maintenance team just to accept a fix for SLE-15-SP1 which will also fix everything later, If its not a "fix" but I still think its useful for older versions I can do lots of paperwork and fill out the ECO* Lubos was talking about in that case someone who gets paid much more then me gets to make the call on whether it is acceptable. If its not then we get option B. Where I need to create a new version of the package for SLE-15-SP3 which could increase maintenance cost especially for some packages so again that additional cost needs to be taken into account, we might decide it is worth it for that feature or we might need to do a new version of that package for other reasons (if this is the case I can probably slip in minor features with almost no paperwork). On the other hand there might be some cases where we decide the feature (especially a minor one) isn't worth the cost of having another version of the package and we might choose to defer the feature until next time we actually need to branch the package for another reason and atleast make sure its in tumbleweed so it automagically finds its way into SLE-16. In all those cases I'm presuming its a feature that probably has a SR already (or it isn't hard to create) and as the maintainer id be happy seeing the SR in tumbleweed. It doesn't take into account features that are going to take X hrs of engineering time to implement in the first place. Or features that I as the maintainer don't believe are a good idea. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B