Hello, Am Montag, 31. August 2020, 13:14:04 CEST schrieb Simon Lees:
On 8/18/20 6:19 AM, Christian Boltz wrote:
Am Montag, 10. August 2020, 12:22:50 CEST schrieb Lubos Kocman:
[Community access to Jira]
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.
That's fine, I already wondered if/why nobody dares to answer ;-)
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,
I know this was a problem, but - playing devil's advocate again - why should this be different/better just because we switch to another tool? And I still think only allowing 10 community members to access Jira would be a serious problem.
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.
I guess that still needs someone who assigns the request to the maintainer, so where's the difference to FATE/openFATE?
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 can't imagine (well, at least I hope) that the product management team didn't have openSUSE in mind when choosing Jira over $alternatives. But if the costs are the only problem you see - AFAIK Atlassian also provides a community license [1]. I don't know the exact conditions and requirements, but in general, we could ask for a community license for openSUSE, which should help to solve the costs argument. And even if openSUSE doesn't qualify for a community license for whatever strange reason, I still think that giving access to all communiy members would be worth the price. [ Personally I wonder why we (both SUSE and openSUSE) need a separate tool for tracking feature requests at all. I'd simply do everything in bugzilla, maybe with a separate "feature requests" product. And yes, I'm aware that bugzilla doesn't let managers do their paperwork (or "workflow") games they like so much in FATE and now Jira and ECO ;-) ]
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.
Please don't abuse GDPR as an argument ;-) GDPR always has the option of permitting something, so if some partners are willing to make their requests public, GDPR won't stop them. NDAs are of course a different beast.
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,
I don't like this idea - it would make Leap a half-rolling release (unless the maintainers take explicit action, as in your fish/fish3 example), and that's not what people expect from Leap.
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)
My latest experience was slightly ;-) different (the details are probably worth a story to tell with a beer^Wglass of wine in reach) and I'm not completely happy about the result - but maybe it was just bad luck and/or bad timing (too close to the freeze). And to make it clear: this is not meant as a complaint about that maintainer - several earlier submissions were accepted without problems.
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.
Thanks for the explanation, it makes things more clear, and highlights the "fun" of handling multiple releases, especially if they share the same version of a package. However, I still wonder if this could be somehow automagically handled so that someone who submits for example an update for 15.2 can just do that without doing any lookups before. Just as an idea - maybe osc could ask something like The package you just submitted is equal in 15.1 and 15.2. Do you want to submit to a) 15.2 b) 15.1 c) both? Regards, Christian Boltz [1] Ask your favorite search engine for "powered by a free Atlassian Jira open source license", and you'll get a long list, for example Apache, Linux Foundation, MariaDB, Moodle, and it seems even Fedora (on https://jira.lyrasis.org) -- Natürlich kann ich Traktor fahren. Ich bin der geborene Traktorfahrer. Es dürfte dir schwer fallen, jemanden zu finden, der annähernd so perfekt Traktor fährt wie ich. Ja, ich _bin_ geradezu ein Traktor. Wieviele Räder hat so ein Traktor eigentlich? [Ratti] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org