Proposal: Update of openSUSE bug reporting policy prior Leap 15.4 Beta
Hello openSUSE! I've had a discussion about Bugzilla triaging for Leap in the past few days and I'd like to present my proposal and work towards having a final "policy" before the Leap 15.4 Beta release. Where we expect increased amount of bugs from the announced Beta testing effort. Since 15.3 and Closing the Leap Gap we have a set of PUBLIC SUSE Linux Enterprise products which unlike traditional SUSE products are by default accessible by community. Big thanks for Vincent, Marina, Gerald and all who participated on the effort. To keep increasing transparency from what's actually being changed under SLE hood we'd like to utilize these as much as possible. This is also the area where the changes in current policy would take place. In the current proposal, nothing is changing for Leap community packages, where priority is set by bug owner and others respect it. Leap Release Manager could still use SHIP_STOPPER / Blocker flags and adjust severity fields to project the impact of community packages on distribution. So that remains the same. The change is basically only for packages inherited from SUSE Linux Enterprise, where packages would be noew preferably created in PUBLIC SUSE Linux* product family, and proactively moved there from openSUSE Distribution by Leap Release Manager (me). Bugs in PUBLIC SLE product family would be then triaged (setting of priority and ownership) by SLE Release Manager. There as part of the transition or we need to keep the priority on the default P5 which means untriaged. There the priority corresponds with impact on the product and therefore should be set only by SLE RM. Any feedback to proposed changes is highly welcome. Let's polish it together prior 15.4 Beta takes place. So far the initial feedback from individuals was good. Changes are visible here: (perhaps I should have used :talk instead). https://en.opensuse.org/index.php?title=openSUSE%3ASubmitting_bug_reports&type=revision&diff=162474&oldid=161022 https://en.opensuse.org/index.php?title=openSUSE%3ABug_definitions&type=revision&diff=162471&oldid=46259 Also relevant but yet unchaged https://en.opensuse.org/openSUSE:Bug_reporting_FAQ -- Best regards Lubos Kocman openSUSE Leap Release Manager
Hello, Am Freitag, 4. Februar 2022, 17:21:43 CET schrieb Lubos Kocman:
I've had a discussion about Bugzilla triaging for Leap in the past few days and I'd like to present my proposal and work towards having a final "policy" before the Leap 15.4 Beta release. Where we expect increased amount of bugs from the announced Beta testing effort. Since 15.3 and Closing the Leap Gap we have a set of PUBLIC SUSE Linux Enterprise products which unlike traditional SUSE products are by default accessible by community. Big thanks for Vincent, Marina, Gerald and all who participated on the effort. To keep increasing transparency from what's actually being changed under SLE hood we'd like to utilize these as much as possible.
As someone who has annoyed lots of people about making SLE bugs open by default since years (actually more than a decade) I'm very happy to hear this :-) BTW: a low-hanging fruit to make more bugs public is probably the "report bug" link in openQA. Is this link set to "PUBLIC SLE" in the SLE tests? (If not, please change it.) Some recent experience also showed me that not all SUSE employees know that the "PUBLIC SLE" product exists (and should be used by default), so some SUSE-internal communication about it might be useful.
The change is basically only for packages inherited from SUSE Linux Enterprise, where packages would be noew preferably created in PUBLIC
I guess s/packages/bugs/ ?
SUSE Linux* product family, and proactively moved there from openSUSE Distribution by Leap Release Manager (me).
It might sound like a silly question, but - what's the reason for moving bugs that were reported for Leap to the PUBLIC SLE products? One problem I see is that the bugzilla search with classification "openSUSE" doesn't include "PUBLIC SLE". Note that classification "openSUSE" is the default on bugzilla.o.o, and can only be changed when you are logged in and know what to change in the user preferences [1]. Therefore "PUBLIC SLE" bugs will be "invisible" to the average bugreporter. This will result in duplicate bugs, people not finding workarounds mentioned in existing bugreports etc. If you really want to move Leap bugs to PUBLIC SLE, please make sure that it becomes part of classification "openSUSE" so that they show up in the default search on bugzilla.o.o.
Bugs in PUBLIC SLE product family would be then triaged (setting of priority and ownership) by SLE Release Manager. There as part of the transition or we need to keep the priority on the default P5 which means untriaged. There the priority corresponds with impact on the product and therefore should be set only by SLE RM.
Nothing stops you or the SLE release managers to set the priority of Leap bugs (and, for completeness, nothing stops community assignees to ignore the prioriy ;-) Regards, Christian Boltz [1] For those who want to adjust their bugzilla preferences: Set "BUI Filter Preference" to "All". -- With the greatest respect to the awesome conference application you have written, it is clear that a DBA wasn't involved. [Joshua D. Drake in opensuse-web]
On Sun, Feb 06, 2022 at 07:47:58PM +0100, Christian Boltz wrote:
Hello,
Am Freitag, 4. Februar 2022, 17:21:43 CET schrieb Lubos Kocman:
I've had a discussion about Bugzilla triaging for Leap in the past few days and I'd like to present my proposal and work towards having a final "policy" before the Leap 15.4 Beta release. Where we expect increased amount of bugs from the announced Beta testing effort. Since 15.3 and Closing the Leap Gap we have a set of PUBLIC SUSE Linux Enterprise products which unlike traditional SUSE products are by default accessible by community. Big thanks for Vincent, Marina, Gerald and all who participated on the effort. To keep increasing transparency from what's actually being changed under SLE hood we'd like to utilize these as much as possible.
As someone who has annoyed lots of people about making SLE bugs open by default since years (actually more than a decade) I'm very happy to hear this :-)
BTW: a low-hanging fruit to make more bugs public is probably the "report bug" link in openQA. Is this link set to "PUBLIC SLE" in the SLE tests? (If not, please change it.)
Some recent experience also showed me that not all SUSE employees know that the "PUBLIC SLE" product exists (and should be used by default), so some SUSE-internal communication about it might be useful.
I am somewhat aware that this opption exists but when I tried to file a public SLE bug I did not manage to find the product in the bugzilla. Bugzilla is swamped with obsolete and no longer supported products so navigating it is difficult and very specific instructions for finding products are needed. Thanks Michal
Michal Suchánek píše v Po 07. 02. 2022 v 13:11 +0100:
On Sun, Feb 06, 2022 at 07:47:58PM +0100, Christian Boltz wrote:
Hello,
Am Freitag, 4. Februar 2022, 17:21:43 CET schrieb Lubos Kocman:
I've had a discussion about Bugzilla triaging for Leap in the past few days and I'd like to present my proposal and work towards having a final "policy" before the Leap 15.4 Beta release. Where we expect increased amount of bugs from the announced Beta testing effort. Since 15.3 and Closing the Leap Gap we have a set of PUBLIC SUSE Linux Enterprise products which unlike traditional SUSE products are by default accessible by community. Big thanks for Vincent, Marina, Gerald and all who participated on the effort. To keep increasing transparency from what's actually being changed under SLE hood we'd like to utilize these as much as possible.
As someone who has annoyed lots of people about making SLE bugs open by default since years (actually more than a decade) I'm very happy to hear this :-)
BTW: a low-hanging fruit to make more bugs public is probably the "report bug" link in openQA. Is this link set to "PUBLIC SLE" in the SLE tests? (If not, please change it.)
Some recent experience also showed me that not all SUSE employees know that the "PUBLIC SLE" product exists (and should be used by default), so some SUSE-internal communication about it might be useful.
I am somewhat aware that this opption exists but when I tried to file a public SLE bug I did not manage to find the product in the bugzilla.
The wiki page is referencing the products. But I believe they were hidden on purpose for historical reason (only visible during Beta testing or so). Perhaps something that Vincent M. and SUSE IT coudl help with.
Bugzilla is swamped with obsolete and no longer supported products so navigating it is difficult and very specific instructions for finding products are needed.
Thanks
Michal
-- Best regards Lubos Kocman openSUSE Leap Release Manager
Hi, Thanks Lubos for starting this! So on top of Lubos’s changes I took the liberty of updating In https://en.opensuse.org/openSUSE:Bug_definitions, since the Prio for openSUSE Bugzilla products is at the discretion of the maintainer, the list of Prio had to be updated to reflect on what the SLE Release Managers actually used. Also I think the following https://en.opensuse.org/openSUSE:Most_annoying_bugs and https://en.opensuse.org/openSUSE:Submitting_bug_reports#Voting_in_Bugzilla could be removed as no one (neither the openSUSE community or the SLE Release Manager?!) is looking or using them? What do you think? Regards, -- Vincent Moutoussamy SUSE Beta Program Manager JeOS Technical Project Manager SLE Container Module Project Manager Paris, France From: Lubos Kocman <lubos.kocman@suse.com> Date: Friday, 4 February 2022 at 17:21 To: opensuse-factory@opensuse.org <opensuse-factory@opensuse.org> Subject: Proposal: Update of openSUSE bug reporting policy prior Leap 15.4 Beta Hello openSUSE! I've had a discussion about Bugzilla triaging for Leap in the past few days and I'd like to present my proposal and work towards having a final "policy" before the Leap 15.4 Beta release. Where we expect increased amount of bugs from the announced Beta testing effort. Since 15.3 and Closing the Leap Gap we have a set of PUBLIC SUSE Linux Enterprise products which unlike traditional SUSE products are by default accessible by community. Big thanks for Vincent, Marina, Gerald and all who participated on the effort. To keep increasing transparency from what's actually being changed under SLE hood we'd like to utilize these as much as possible. This is also the area where the changes in current policy would take place. In the current proposal, nothing is changing for Leap community packages, where priority is set by bug owner and others respect it. Leap Release Manager could still use SHIP_STOPPER / Blocker flags and adjust severity fields to project the impact of community packages on distribution. So that remains the same. The change is basically only for packages inherited from SUSE Linux Enterprise, where packages would be noew preferably created in PUBLIC SUSE Linux* product family, and proactively moved there from openSUSE Distribution by Leap Release Manager (me). Bugs in PUBLIC SLE product family would be then triaged (setting of priority and ownership) by SLE Release Manager. There as part of the transition or we need to keep the priority on the default P5 which means untriaged. There the priority corresponds with impact on the product and therefore should be set only by SLE RM. Any feedback to proposed changes is highly welcome. Let's polish it together prior 15.4 Beta takes place. So far the initial feedback from individuals was good. Changes are visible here: (perhaps I should have used :talk instead). https://en.opensuse.org/index.php?title=openSUSE%3ASubmitting_bug_reports&type=revision&diff=162474&oldid=161022 https://en.opensuse.org/index.php?title=openSUSE%3ABug_definitions&type=revision&diff=162471&oldid=46259 Also relevant but yet unchaged https://en.opensuse.org/openSUSE:Bug_reporting_FAQ -- Best regards Lubos Kocman openSUSE Leap Release Manager
On 2022-02-07 17:29, Vincent Moutoussamy wrote:
Also I think the following https://en.opensuse.org/openSUSE:Most_annoying_bugs <https://en.opensuse.org/openSUSE:Most_annoying_bugs> and https://en.opensuse.org/openSUSE:Submitting_bug_reports#Voting_in_Bugzilla <https://en.opensuse.org/openSUSE:Submitting_bug_reports#Voting_in_Bugzilla> could be removed as no one (neither the openSUSE community or the SLE Release Manager?!) is looking or using them?
We do look at them, and do not like seeing them empty. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
Also I think the following https://en.opensuse.org/openSUSE:Most_annoying_bugs <https://en.opensuse.org/openSUSE:Most_annoying_bugs> and https://en.opensuse.org/openSUSE:Submitting_bug_reports#Voting_in_Bugzilla <https://en.opensuse.org/openSUSE:Submitting_bug_reports#Voting_in_Bugzilla> could be removed as no one (neither the openSUSE community or the SLE Release Manager?!) is looking or using them?
Voting on bugs just came up in a discussion I had today. I think the section quoting "Voting in Bugzilla is intended for orientation purposes only" is fine as it is.
Oliver Kurz píše v St 09. 02. 2022 v 16:39 +0100:
Also I think the following https://en.opensuse.org/openSUSE:Most_annoying_bugs <https://en.opensuse.org/openSUSE:Most_annoying_bugs> and https://en.opensuse.org/openSUSE:Submitting_bug_reports#Voting_in_Bugzilla < https://en.opensuse.org/openSUSE:Submitting_bug_reports#Voting_in_Bu gzilla> could be removed as no one (neither the openSUSE community or the SLE Release Manager?!) is looking or using them?
Voting on bugs just came up in a discussion I had today. I think the section quoting "Voting in Bugzilla is intended for orientation purposes only" is fine as it is. Thank you Oliver!
Meanwhile I've reported the visibility of the product during bug reporting as an RFE to SUSE IT department (SD-76713). I expect we'll be able to improve this prior end of February, so just in time for Beta. -- Best regards Lubos Kocman openSUSE Leap Release Manager
I did share the proposal with other technical project managers and so far I received good fedback. One topic which we still seem to struggle with or is bit unclear is priority definitions on the openSUSE wiki. We claim that openSUSE priorization is done by bugowner to simply priorize his backlog, but we present priorities in let's say SUSE fashion, which I'm not sure is useful for the community bugowner. To me it would make sense to present priorities in a much simplier way for community owned bugs, and update table to match priority table for SLES bugs and present it in the way that these is how SLES is using priority and not necessarily openSUSE. What are your thoughts? Lubos Kocman píše v Čt 10. 02. 2022 v 13:13 +0000:
Oliver Kurz píše v St 09. 02. 2022 v 16:39 +0100:
Also I think the following https://en.opensuse.org/openSUSE:Most_annoying_bugs <https://en.opensuse.org/openSUSE:Most_annoying_bugs> and https://en.opensuse.org/openSUSE:Submitting_bug_reports#Voting_in_Bugzilla < https://en.opensuse.org/openSUSE:Submitting_bug_reports#Voting_in_Bu gzilla> could be removed as no one (neither the openSUSE community or the SLE Release Manager?!) is looking or using them?
Voting on bugs just came up in a discussion I had today. I think the section quoting "Voting in Bugzilla is intended for orientation purposes only" is fine as it is. Thank you Oliver!
Meanwhile I've reported the visibility of the product during bug reporting as an RFE to SUSE IT department (SD-76713). I expect we'll be able to improve this prior end of February, so just in time for Beta.
-- Best regards
Lubos Kocman openSUSE Leap Release Manager
-- Best regards Lubos Kocman openSUSE Leap Release Manager
10.02.2022 18:02:01 Lubos Kocman <lubos.kocman@suse.com>:
I did share the proposal with other technical project managers and so far I received good fedback.
One topic which we still seem to struggle with or is bit unclear is priority definitions on the openSUSE wiki.
We claim that openSUSE priorization is done by bugowner to simply priorize his backlog, but we present priorities in let's say SUSE fashion, which I'm not sure is useful for the community bugowner.
To me it would make sense to present priorities in a much simplier way for community owned bugs, and update table to match priority table for SLES bugs and present it in the way that these is how SLES is using priority and not necessarily openSUSE.
What are your thoughts?
I would say priority commonly doesn't have a useful meaning in the scope of openSUSE. It would have a useful meaning if there is a central instance deciding about priorities so that comparing bugs with different properties makes sense. IMHO release managers for the according distribution should ensure that. Meaning, they can either set prios themselves or make sure it happens by others
Lubos Kocman píše v Čt 10. 02. 2022 v 13:13 +0000:
Oliver Kurz píše v St 09. 02. 2022 v 16:39 +0100:
Also I think the following https://en.opensuse.org/openSUSE:Most_annoying_bugs <https://en.opensuse.org/openSUSE:Most_annoying_bugs> and https://en.opensuse.org/openSUSE:Submitting_bug_reports#Voting_in_Bugzilla < https://en.opensuse.org/openSUSE:Submitting_bug_reports#Voting_in_Bu gzilla> could be removed as no one (neither the openSUSE community or the SLE Release Manager?!) is looking or using them?
Voting on bugs just came up in a discussion I had today. I think the section quoting "Voting in Bugzilla is intended for orientation purposes only" is fine as it is. Thank you Oliver!
Meanwhile I've reported the visibility of the product during bug reporting as an RFE to SUSE IT department (SD-76713). I expect we'll be able to improve this prior end of February, so just in time for Beta.
-- Best regards
Lubos Kocman openSUSE Leap Release Manager
-- Best regards
Lubos Kocman openSUSE Leap Release Manager
Oliver Kurz píše v Čt 10. 02. 2022 v 17:48 +0000:
10.02.2022 18:02:01 Lubos Kocman <lubos.kocman@suse.com>:
I did share the proposal with other technical project managers and so far I received good fedback.
One topic which we still seem to struggle with or is bit unclear is priority definitions on the openSUSE wiki.
We claim that openSUSE priorization is done by bugowner to simply priorize his backlog, but we present priorities in let's say SUSE fashion, which I'm not sure is useful for the community bugowner.
To me it would make sense to present priorities in a much simplier way for community owned bugs, and update table to match priority table for SLES bugs and present it in the way that these is how SLES is using priority and not necessarily openSUSE.
What are your thoughts?
I would say priority commonly doesn't have a useful meaning in the scope of openSUSE. It would have a useful meaning if there is a central instance deciding about priorities so that comparing bugs with different properties makes sense. IMHO release managers for the according distribution should ensure that. Meaning, they can either set prios themselves or make sure it happens by others
I fully agree Oliver, that's exactly what I meant by the more simplified way. Could be a single paragraph that presents typical backlog priorization techniques.
Lubos Kocman píše v Čt 10. 02. 2022 v 13:13 +0000:
Oliver Kurz píše v St 09. 02. 2022 v 16:39 +0100:
Also I think the following https://en.opensuse.org/openSUSE:Most_annoying_bugs <https://en.opensuse.org/openSUSE:Most_annoying_bugs> and https://en.opensuse.org/openSUSE:Submitting_bug_reports#Voting_in_Bugzilla < https://en.opensuse.org/openSUSE:Submitting_bug_reports#Voting_in_Bu gzilla> could be removed as no one (neither the openSUSE community or the SLE Release Manager?!) is looking or using them?
Voting on bugs just came up in a discussion I had today. I think the section quoting "Voting in Bugzilla is intended for orientation purposes only" is fine as it is. Thank you Oliver!
Meanwhile I've reported the visibility of the product during bug reporting as an RFE to SUSE IT department (SD-76713). I expect we'll be able to improve this prior end of February, so just in time for Beta.
-- Best regards
Lubos Kocman openSUSE Leap Release Manager
-- Best regards
Lubos Kocman openSUSE Leap Release Manager
-- Best regards Lubos Kocman openSUSE Leap Release Manager
participants (6)
-
Carlos E. R. -
Christian Boltz -
Lubos Kocman -
Michal Suchánek -
Oliver Kurz -
Vincent Moutoussamy