[opensuse-factory] New submit request workflow for Jump, publicly available builds
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
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
On Mon, 2020-08-17 at 14:07 +0200, Dan Čermák wrote:
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?
+100! It's not only a frustrating situation for openSUSE maintainers who do not work for SUSE. I maintain some packages in Factory under my role at SUSE, but there is a whole other team with the formal responsibility for those packages in SUSE's commercial products (and therefore also Leap/Jump). I like to think I do a good job of avoiding the tensions you describe here, with openSUSE maintainers trying to prevent stuff landing in SLE. I'm never going to intentionally make changes to my packages to make things harder to include in SUSE Products and am ALWAYS open to collaboration with others to make things easier for my packages to be consumed wherever people want to consume them. But I am witness to a significant number of cases of the inverse; Some SUSE Commericial products actively try to prevent Factory packages landing in their product, despite SUSE's own policies stating otherwise. Such a practice doesn't help anyone, and I would very much like to see Jump help address such bad practice. I'd also like it if people didn't always assume I owned all the packages in all the codebases, as helpful as I like to be, keeping my stuff in a good condition in Tumbleweed/Kubic is enough for me ;) Regards, Rich -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2020-08-17 14:07, Dan Čermák wrote:
Lubos Kocman <lubos.kocman@suse.com> writes:
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?
Why creating another issue/request in another tool? What about ...
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
... directly creating the SR to Jump? (of course after landing in oS:F) The TAM or whoever at SUSE can review there as well. I do not see the need for an extra Jira issue. OBS SRs _are_ issues which can nicely be tracked. Of course it's possible that I missed something ... Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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
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
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
On Tue, Sep 1, 2020 at 6:25 PM Christian Boltz <opensuse@cboltz.de> wrote:
Hello,
Am Montag, 31. August 2020, 13:14:04 CEST schrieb Simon Lees:
On 8/18/20 6:19 AM, Christian Boltz wrote:
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 ;-) ]
[...]
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)
I knew one day the wacky situation with the Fedora name was going to bite us. :) There are actually *two* projects called "Fedora". This is the _other_ Fedora project that is a digital content repository system[1]. There is a standing agreement that permits Red Hat and Cornell-UVA (and now DuraSpace) to use the Fedora name for their respective projects, given that they do not intersect in the same market verticals. DuraSpace Fedora is a CMS, and Red Hat Fedora is the Linux platform[2]. [1]: https://duraspace.org/fedora/about/ [2]: https://docs.fedoraproject.org/en-US/project/ -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Sep 2, 2020 at 00:25, Christian Boltz <opensuse@cboltz.de> wrote:
[ 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 ;-) ]
From my interactions with the upstream of Bugzilla, they are hard working, well meaning bunch, that sadly, as many other open source project, get hung up on not having enough contributors. Even though they have the next release of Bugzilla almost ready, they don't have the resources required to sufficiently test migrations, do testing and otherwise prepare for the release. They were affected real bad by the layoffs at Mozilla this and last year. If you have the time to spare, any help is appreciated https://www.bugzilla.org/developers/ Maybe it would be good to develop more in a direction that appeals more to management types so Bugzilla doesn't look so alien to them ;) LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2020-09-02 00:25, Christian Boltz wrote:
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.
That seems to be in place: I created https://build.opensuse.org/request/show/830301 for a Base:System package and targeting openSUSE:Jump:15.2 (as indicated on the wiki), and the system turned it automagically to target SUSE:SLE-15:GA. Is that what you mean? FWIW: this is all that I need - I mean I don't need extra requests in Jira or whatever tool to manage requests we anyway do with 'osc' / on OBS. Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 9/2/20 7:55 AM, Christian Boltz wrote:
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 ;-)
I was off sick :-)
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?
Its less about switching to another tool and more about the fact that SUSE is committing resource to do this job now (they weren't doing so in the openSUSE instance of open fate).
And I still think only allowing 10 community members to access Jira would be a serious problem.
Agreed. I believe 10 people is an "Initial pilot program" and it will open up further in the future.
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?
Yep as I said above SUSE has committed to dedicating resource to do this in the same way as they do for there partners, the difference is SUSE no longer uses FATE to do this so using fate would create 2 different processes rather then one.
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.
We don't qualify this discussion was already had. Part of the reason is openSUSE doesn't have an independent legal structure, another part I think was we are too tightly tied to SUSE there may have been other reasons. I only heard these third hand but my impression was that because we don't have a foundation its easy for them to say no, but even if we did have a foundation they'd probably find other ways to say no.
[ 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 ;-) ]
Beyond that our current bugzilla doesn't have fine grain enough access control on issues among other things, I also believe due to time constraints developing something internally was out of the question and I believe they equally wanted a system they didn't have to host and maintain in house.
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.
Yep but that requires support in the tooling to ask this option :-) Cheers -- 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
participants (8)
-
Bernhard Voelker -
Christian Boltz -
Dan Čermák -
Lubos Kocman -
Neal Gompa -
Richard Brown -
Simon Lees -
Stasiek Michalski