I've talked about this before, but maybe the F26 cycle is time to make it happen. Right now, we have only one way of saying "this bug is important to the project as a whole; could we please get resources focused on it?" — and that way is to stop the whole vehicle until someone does something about it. This has always been kind of problematic, even though it has served well enough so far... but as we move to more deliverables and add things with different lifecycles, I think we need something else.
We have the Accepted Blockers https://qa.fedoraproject.org/blockerbugs/milestone/25/final/buglist list. The process is nicely documented at https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process; please read that if you're not familiar.
I propose we create a parallel "Critical Issues" list, using basically the same procedures. Issues eligible for this status would be those which do not necessarily fail a release criterion but which have critical impact on a Fedora Edition or on a council-approved Fedora Objective.
Since Fedora is a volunteer process, this can't be backed by a hard mandate (like the "block the release!" emergency brake), but if we agree together to take it seriously, I think it will still provide a useful list. Anyone with a package or component involved in the issue will be able to see the impact, and take that into account when prioritizing. As FPL, it'd give me a nice overview of issues that might need extra resources or coordination.
We could either implement this by extending the existing blocker bug process — adding a new tracker bug, add a new category in the blockerbug app, and review candidate issues at the normal blocker review meetings. Or, it could be done in parallel, with a separately-configured instance of the blockerbug app and with review in a separate meeting called as needed (or maybe just FESCo?)
As with the existing Blocker or Freeze Exception levels, we could also introduce a second tier "Important Issues", which could have a wider net than the rules for "Critical Issues". I'm not sure about that.
In any case, what do you all think?
On Wed, Oct 05, 2016 at 13:29:41 -0500, Michael Cronenworth mike@cchtml.com wrote:
On 10/05/2016 01:19 PM, Matthew Miller wrote:
In any case, what do you all think?
What happened to the Nice-To-Have (NTH) tag?
It was renamed to freeze exception. But it covers a different set of fixes. Those are bugs that are worth breaking a freeze in order to get a fix in, but aren't worth delaying the release for.
The issue we are trying to fix, is getting important bugs (blocker or not) attention from people who are capable of fixing them. That can sometimes be hard to do.
On Wed, 5 Oct 2016 13:29:41 -0500 Michael Cronenworth mike@cchtml.com wrote:
On 10/05/2016 01:19 PM, Matthew Miller wrote:
In any case, what do you all think?
What happened to the Nice-To-Have (NTH) tag?
It was renamed to "Freeze Exception" to better match what we were actually doing with that tracker bug.
The purpose of the Freeze Exception (formerly NTH) bugs is to mark issues which are serious but not blockers which generally can't be fixed through a 0-day release. If a working fix becomes available during freeze, that fix will be eligible to be pulled into stable as a special case.
Tim
On Wed, Oct 05, 2016 at 14:19:12 -0400, Matthew Miller mattdm@fedoraproject.org wrote:
In any case, what do you all think?
I don't think the tracking side would be hard to do. What I'd like to hear about is how the list will work for getting bugs better fixed than bugzilla entries will? Is this something people paid to work on Fedora (or perhaps centos and rhel for bugs in common with Fedora) can use to change their work priorities? Are we going to hope that volunteers will be more likely to notice bugs on this list than bugzilla. Or perhaps we hope to recruit volunteers who wouldn't normally work on a package to help out for these important bugs? (There are some really good packagers who could help out almost anywhere but obviously have limited time and can't help everywhere.)
Hi,
On 05-10-16 20:30, Bruno Wolff III wrote:
On Wed, Oct 05, 2016 at 14:19:12 -0400, Matthew Miller mattdm@fedoraproject.org wrote:
In any case, what do you all think?
I don't think the tracking side would be hard to do. What I'd like to hear about is how the list will work for getting bugs better fixed than bugzilla entries will? Is this something people paid to work on Fedora (or perhaps centos and rhel for bugs in common with Fedora) can use to change their work priorities? Are we going to hope that volunteers will be more likely to notice bugs on this list than bugzilla. Or perhaps we hope to recruit volunteers who wouldn't normally work on a package to help out for these important bugs? (There are some really good packagers who could help out almost anywhere but obviously have limited time and can't help everywhere.)
Speaking for myself only here, my experience in the gfx team is that there are so many bugs that I cannot see the forest through the trees.
A list with issues which are not blockers, but only barely so and it would be really really good to have them fixed, would certainly be a list I would look at and see if there is anything on there I can pick up.
So I like the idea, I do propose to simply re-use most of the blocker bug process for this, rather then inventing yet another process. I guess this could even be integrated and the way to get bugs on the list would be to propose them as blockers as normal and then during the blocker meeting when the vote says "no this is not a blocker" a second vote is done to see if it is a critical bug.
Regards,
Hans
On Thu, 2016-10-06 at 10:39 +0200, Hans de Goede wrote:
So I like the idea, I do propose to simply re-use most of the blocker bug process for this, rather then inventing yet another process. I guess this could even be integrated and the way to get bugs on the list would be to propose them as blockers as normal and then during the blocker meeting when the vote says "no this is not a blocker" a second vote is done to see if it is a critical bug.
Let me phrase my earlier objection a little more strongly and personally:
If someone tries to make me spend another three damn hours a week reviewing 'proposed critical bugs' I'm going to jump out a window and go start that yak farm. You won't see me for dust.
:P
On 10/06/2016 03:27 PM, Adam Williamson wrote:
On Thu, 2016-10-06 at 10:39 +0200, Hans de Goede wrote:
So I like the idea, I do propose to simply re-use most of the blocker bug process for this, rather then inventing yet another process. I guess this could even be integrated and the way to get bugs on the list would be to propose them as blockers as normal and then during the blocker meeting when the vote says "no this is not a blocker" a second vote is done to see if it is a critical bug.
Let me phrase my earlier objection a little more strongly and personally:
If someone tries to make me spend another three damn hours a week reviewing 'proposed critical bugs' I'm going to jump out a window and go start that yak farm. You won't see me for dust.
Interesting to see that now the person responsible for adding additional load on the QA community want's to jump out of windows after doing so. You reap what you sow...
As I mentioned sometime back in my QA days, QA should just take care of the installer/core/baseOS, then each sub community that delivers an product of some sort into the hands of an end users needs to take care of QA-ing it itself for whatever it builds on top of that and arguably the rest of the release process for that product.
Then the release process needs to be scaled from supporting just a single product ( which has never reflected what the community has ever done since there have always been more then one product in circulation from the community ) designed in such manner that product A cant block product B or C or F.
I have never understood this whole attitude of always putting all the load on QA and Releng which has never had any resources to effectively manage it for everybody to begin with.
JBG
Speaking for myself only here, my experience in the gfx team is that there are so many bugs that I cannot see the forest through the trees.
A list with issues which are not blockers, but only barely so and it would be really really good to have them fixed, would certainly be a list I would look at and see if there is anything on there I can pick up.
So I like the idea, I do propose to simply re-use most of the blocker bug process for this, rather then inventing yet another process. I guess this could even be integrated and the way to get bugs on the list would be to propose them as blockers as normal and then during the blocker meeting when the vote says "no this is not a blocker" a second vote is done to see if it is a critical bug.
As already mentioned, the CommonBugs page might actually fit most of the requirements here. We often place important "almost blocker" bugs in there, issues which are very inconvenient for many people, or critical issues for a specific narrow group of people. If we know it's being used even by developers, we might try harder to include important issues in there. It's not exactly the same idea that Matthew talked about, but I think the overlap is definitely there. As a bonus, there's a quick summary of the issue (which someone has to write, on the other hand, of course).
On Wed, Oct 5, 2016 at 12:19 PM, Matthew Miller mattdm@fedoraproject.org wrote:
I've talked about this before, but maybe the F26 cycle is time to make it happen. Right now, we have only one way of saying "this bug is important to the project as a whole; could we please get resources focused on it?" — and that way is to stop the whole vehicle until someone does something about it. This has always been kind of problematic, even though it has served well enough so far... but as we move to more deliverables and add things with different lifecycles, I think we need something else.
We have the Accepted Blockers https://qa.fedoraproject.org/blockerbugs/milestone/25/final/buglist list. The process is nicely documented at https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process; please read that if you're not familiar.
I propose we create a parallel "Critical Issues" list, using basically the same procedures. Issues eligible for this status would be those which do not necessarily fail a release criterion but which have critical impact on a Fedora Edition or on a council-approved Fedora Objective.
Since Fedora is a volunteer process, this can't be backed by a hard mandate (like the "block the release!" emergency brake), but if we agree together to take it seriously, I think it will still provide a useful list. Anyone with a package or component involved in the issue will be able to see the impact, and take that into account when prioritizing. As FPL, it'd give me a nice overview of issues that might need extra resources or coordination.
We could either implement this by extending the existing blocker bug process — adding a new tracker bug, add a new category in the blockerbug app, and review candidate issues at the normal blocker review meetings. Or, it could be done in parallel, with a separately-configured instance of the blockerbug app and with review in a separate meeting called as needed (or maybe just FESCo?)
As with the existing Blocker or Freeze Exception levels, we could also introduce a second tier "Important Issues", which could have a wider net than the rules for "Critical Issues". I'm not sure about that.
In any case, what do you all think?
If this can be prominently included in a concise "how you can help make Fedora better" as a form of contributor recruitment, it'd probably be more enticing as well as helpful. If there were some consolidated, yet sortable list of To Do's: sortable by priority, and by expertise needed, and maybe an effort estimate, I think we'd find many small things getting more attention. It'd be easy to dive in, do something, finish it, and duck out.
A way of advertising a path to getting more intermediate-expert types, rather than having to always depend on the same people for blockers and big fixes every release.
Also a nice to have with this would be a Fantasy Fedora mechanism. A way to put together a virtual team and send out invites: here's something that needs work, what do you three people think of solving this problem together?
On Wed, Oct 5, 2016 at 3:16 PM, Chris Murphy lists@colorremedies.com wrote:
On Wed, Oct 5, 2016 at 12:19 PM, Matthew Miller mattdm@fedoraproject.org wrote:
I've talked about this before, but maybe the F26 cycle is time to make it happen. Right now, we have only one way of saying "this bug is important to the project as a whole; could we please get resources focused on it?" — and that way is to stop the whole vehicle until someone does something about it. This has always been kind of problematic, even though it has served well enough so far... but as we move to more deliverables and add things with different lifecycles, I think we need something else.
We have the Accepted Blockers https://qa.fedoraproject.org/blockerbugs/milestone/25/final/buglist list. The process is nicely documented at https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process; please read that if you're not familiar.
I propose we create a parallel "Critical Issues" list, using basically the same procedures. Issues eligible for this status would be those which do not necessarily fail a release criterion but which have critical impact on a Fedora Edition or on a council-approved Fedora Objective.
Since Fedora is a volunteer process, this can't be backed by a hard mandate (like the "block the release!" emergency brake), but if we agree together to take it seriously, I think it will still provide a useful list. Anyone with a package or component involved in the issue will be able to see the impact, and take that into account when prioritizing. As FPL, it'd give me a nice overview of issues that might need extra resources or coordination.
We could either implement this by extending the existing blocker bug process — adding a new tracker bug, add a new category in the blockerbug app, and review candidate issues at the normal blocker review meetings. Or, it could be done in parallel, with a separately-configured instance of the blockerbug app and with review in a separate meeting called as needed (or maybe just FESCo?)
As with the existing Blocker or Freeze Exception levels, we could also introduce a second tier "Important Issues", which could have a wider net than the rules for "Critical Issues". I'm not sure about that.
In any case, what do you all think?
If this can be prominently included in a concise "how you can help make Fedora better" as a form of contributor recruitment, it'd probably be more enticing as well as helpful. If there were some
The issue I see with that is if these are critical fixes that aren't being fixed, the likelyhood of a new contributor coming in and fixing them in a timely fashion is pretty low. What Matthew is really after is a prioritization problem for critical resources.
consolidated, yet sortable list of To Do's: sortable by priority, and by expertise needed, and maybe an effort estimate, I think we'd find many small things getting more attention. It'd be easy to dive in, do something, finish it, and duck out.
That is completely orthogonal to what Matthew is talking about. We already have 'what can you do for Fedora' so if we need to expand that, let's start a different discussion.
A way of advertising a path to getting more intermediate-expert types, rather than having to always depend on the same people for blockers and big fixes every release.
Where do you foresee these people coming from? Or rather, why aren't they already involved?
Also a nice to have with this would be a Fantasy Fedora mechanism. A way to put together a virtual team and send out invites: here's something that needs work, what do you three people think of solving this problem together?
How is that not just sending an email?
josh
Giant +1
There are few things more frustrating than being bitten by a bug that goes unfixed for release after release, while being told by the maintainer that they simply don't have time to fix anything but release blockers.
This wouldn't automaticall fix this, but it would certainly provide a strong signal that a bug is deemed worthy of attention by someone other than the reporter.
On Wed, 5 Oct 2016 14:19:12 -0400 Matthew Miller mattdm@fedoraproject.org wrote:
...snip...
In any case, what do you all think?
Well, we sort of have something like this today: common bugs. ie, things we think people will hit and we couldn't/didn't fix in time for release? But we only do those around milestones and I guess this might be more coverage for other times...
I'm willing to try a more formal system, but I'm not convinced it will help out too much.
kevin
On Wed, 2016-10-05 at 14:19 -0400, Matthew Miller wrote:
I propose we create a parallel "Critical Issues" list, using basically the same procedures. Issues eligible for this status would be those which do not necessarily fail a release criterion but which have critical impact on a Fedora Edition or on a council-approved Fedora Objective.
So how is this any different from freeze exceptions? Your email acknowledges that freeze exceptions already exist, but doesn't describe how you envision critical issues to function differently. What makes an issue a freeze exception and not a critical issue, or vice-versa?
Probably would should just use the existing freeze exception process for this purpose? What's the benefit of adding another thing?
Michael
On Wed, 2016-10-05 at 16:26 -0500, Michael Catanzaro wrote:
Probably would should just use the existing freeze exception process for this purpose? What's the benefit of adding another thing?
One thing about the freeze exception process is that we only actually review proposed freeze exceptions when it makes sense to - i.e. when we're actually in (or about to enter) a freeze. So there can be quite long periods when proposed freeze exceptions aren't being reviewed.
There can also be bugs that are freeze exceptions but aren't actually terribly important, funny as it may sound. For instance, we typically grant freeze exceptions for fixing dependency errors, even if the package with the error is something incredibly obscure that only two people care about, just on the basis that it's nice to have as few consistency issues in the 'frozen' release trees as possible. But if it's a pretty obscure package, that's not really a terribly *important* bug, it's just a cleanliness thing.
Another example along those lines...any non-blocking image being larger than it's supposed to be is an automatic FE. But again, is it really that *important* if the Astronomy spin is 10MiB too big? No disrespect to our astronomer friends :)
The reverse case is also possible: there can be bugs that are quite important but which it makes no sense to grant a freeze exception to, because getting the fix into the frozen package set for a given milestone isn't actually necessary to solve the problem.
So...the freeze exception bug list is actually not as good a proxy for 'non-blocker bugs we really care a lot about' as you might think.
On Wed, Oct 05, 2016 at 16:26:54 -0500, Michael Catanzaro mcatanzaro@gnome.org wrote:
On Wed, 2016-10-05 at 14:19 -0400, Matthew Miller wrote:
I propose we create a parallel "Critical Issues" list, using basically the same procedures. Issues eligible for this status would be those which do not necessarily fail a release criterion but which have critical impact on a Fedora Edition or on a council-approved Fedora Objective.
So how is this any different from freeze exceptions? Your email acknowledges that freeze exceptions already exist, but doesn't describe how you envision critical issues to function differently. What makes an issue a freeze exception and not a critical issue, or vice-versa?
Freeze exceptions don't have to be critical bugs if they are low risk. For example fixes to packages that are on a non-releasing blocking spin can have a very low bar to cross since the chance of introducing a new blocker is very low.
Probably would should just use the existing freeze exception process for this purpose? What's the benefit of adding another thing?
The freeze exceptions are often requested when there is already a fix or when one is anticipated. The list hasn't been useful for getting people to fix bugs that otherwise weren't being worked on.
On Wed, 2016-10-05 at 14:19 -0400, Matthew Miller wrote:
I've talked about this before, but maybe the F26 cycle is time to make it happen. Right now, we have only one way of saying "this bug is important to the project as a whole; could we please get resources focused on it?" — and that way is to stop the whole vehicle until someone does something about it. This has always been kind of problematic, even though it has served well enough so far... but as we move to more deliverables and add things with different lifecycles, I think we need something else.
We have the Accepted Blockers https://qa.fedoraproject.org/blockerbugs/milestone/25/final/buglist list. The process is nicely documented at https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process; please read that if you're not familiar.
I propose we create a parallel "Critical Issues" list, using basically the same procedures. Issues eligible for this status would be those which do not necessarily fail a release criterion but which have critical impact on a Fedora Edition or on a council-approved Fedora Objective.
We used to have exactly this, up until Fedora 14. We had 'Target' trackers as well as 'Blocker' trackers. Fedora 14 was in fact a rather special release as it had all three concepts: 'blocker', 'freeze exception' (though we called these something else at the time) and 'target'. (F13 had a 'Target' tracker but no freeze exception trackers, F15 had blocker and freeze exception trackers but no 'Target' tracker). Here's the F14 Beta blocker tracker:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=611991
the Beta freeze exception tracker:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=634253
and the 'Target' tracker (we never split these by milestone):
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=538278
The Target trackers were discontinued, so far as I recall, because no- one ever really took a blind bit of notice of them. People would throw bugs onto the list and then...nothing much would happen. It was just kind of a wishlist and (IIRC) very few packagers even looked at it, and even those involved in release wrangling had enough on their plates just dealing with the blocker list.
At that point the blocker process was rather less defined than it is now, and there was absolutely no kind of 'process' around the Target tracker - it just got created, there was no kind of process that made it anyone's job to actually care about the bugs on the list - so it's possible that this idea could fly better with some kind of process around it. But I think it's worth noting we had this before and explicitly stopped doing it because it was kinda pointless.
We could either implement this by extending the existing blocker bug process — adding a new tracker bug, add a new category in the blockerbug app, and review candidate issues at the normal blocker review meetings. Or, it could be done in parallel, with a separately-configured instance of the blockerbug app and with review in a separate meeting called as needed (or maybe just FESCo?)
As with the existing Blocker or Freeze Exception levels, we could also introduce a second tier "Important Issues", which could have a wider net than the rules for "Critical Issues". I'm not sure about that.
In any case, what do you all think?
Blocker review is a rather resource-intensive process, where the resource involved are of the squishy human kind. I'm not sure anyone would be super-thrilled about spending several *extra* hours per week having bunfights about whether an issue is 'critical' or 'important'. I think if we're gonna go with this it might make sense to use a rather lighter process than the blocker review process, though I don't have a specific proposal for how that could look at this point in time. If it would mainly be used by the FPL and FPM, perhaps it could simply be the rule that they got to decide what bugs went on it?
Adam Williamson wrote:
The Target trackers were discontinued, so far as I recall, because no- one ever really took a blind bit of notice of them. People would throw bugs onto the list and then...nothing much would happen. It was just kind of a wishlist and (IIRC) very few packagers even looked at it, and even those involved in release wrangling had enough on their plates just dealing with the blocker list.
That's exactly the problem with such a process with no enforcement. I also doubt it is going to work.
Blocker review is a rather resource-intensive process, where the resource involved are of the squishy human kind. I'm not sure anyone would be super-thrilled about spending several *extra* hours per week having bunfights about whether an issue is 'critical' or 'important'. I think if we're gonna go with this it might make sense to use a rather lighter process than the blocker review process, though I don't have a specific proposal for how that could look at this point in time. If it would mainly be used by the FPL and FPM, perhaps it could simply be the rule that they got to decide what bugs went on it?
Why would this need a centralized process at all? Why not just let the affected SIG or WG decide?
In fact, I would argue that this should even be done for blockers: A bug should be a blocker if and only if a SIG/WG behind a release-blocking image decides that it is important for it to be fixed in the release, no matter whether it fits into any kind of global formal criteria. And punting blockers should also only be possible if the responsible SIG/WG agrees with it. As long as the SIGs and WGs for all release-blocking images have not signed off on the release, we should slip, even if it takes weeks (and to avoid long freezes, a slip should consist of accepting ALL pending updates and restarting the freeze process from scratch – that should also singificantly reduce the need for freeze exceptions).
Kevin Kofler
On Thu, 2016-10-06 at 00:36 +0200, Kevin Kofler wrote:
In fact, I would argue that this should even be done for blockers: A bug should be a blocker if and only if a SIG/WG behind a release-blocking image decides that it is important for it to be fixed in the release, no matter whether it fits into any kind of global formal criteria.
We base the criteria heavily on SIG/WG input. I prefer this to the idea of just letting SIGs/WGs declare whether bugs are blockers because the point of the criteria is to try to produce consistent and predictable decisions, so far as that's possible; if we just say 'blockers are whatever SIGs decide' we're either going to get inconsistent decisions, or we're going to have each SIG/WG having to do the work of implementing criteria and a blocker review process separately, which just seems like extra bureaucracy.
If you're unhappy with any of the criteria from a KDE perspective, we absolutely can adjust them. We want the criteria to be agreed upon, they're not carved in stone and imposed upon you.
Also, as a practical matter, the people who mainly actually show up to do the work of blocker review are QA, releng and 'management' folks (i.e. FPL and FPM). In theory blocker review is supposed to be done with equal input from QA, 'development', releng and 'management', but in practice we rarely get many 'development' folks showing up. sgallagh is usually there and could be counted as a Server rep, we sometimes get someone from Workstation, but there's rarely anyone from Cloud or KDE (apologies if I'm forgetting anyone).
And punting blockers should also only be possible if the responsible SIG/WG agrees with it. As long as the SIGs and WGs for all release-blocking images have not signed off on the release, we should slip, even if it takes weeks (and to avoid long freezes, a slip should consist of accepting ALL pending updates and restarting the freeze process from scratch – that should also singificantly reduce the need for freeze exceptions).
I don't think this would be an improvement. As long as a 'Fedora release' is as big and messy of a thing as it is right now, involving a zillion deliverables and teams, I don't think it makes sense to declare that certain groups have a complete veto on shipping. The current process is pretty collaborative between all the stakeholder groups, I'd say.
On Thu, 2016-10-06 at 00:36 +0200, Kevin Kofler wrote:
In fact, I would argue that this should even be done for blockers: A bug should be a blocker if and only if a SIG/WG behind a release-blocking image decides that it is important for it to be fixed in the release, no matter whether it fits into any kind of global formal criteria.
Hi,
If the Workstation WG were to have such a responsibility, I strongly suspect we would prefer to delegate it to the existing QA team and blocker bug process. It's been working pretty well for us and the WG is not set up to handle minutiae like this.
We might meddle with the blocker criteria from time to time by requesting new blocker criteria to fit a particular bug, but in general I don't think it would be helpful to turn WG meetings into blocker review meetings. The QA folks who currently handle blocker review are doing a better job than we could anyway.
Michael
On Wed, Oct 05, 2016 at 02:33:37PM -0700, Adam Williamson wrote:
We used to have exactly this, up until Fedora 14. We had 'Target'
[much snip]
lighter process than the blocker review process, though I don't have a specific proposal for how that could look at this point in time. If it would mainly be used by the FPL and FPM, perhaps it could simply be the rule that they got to decide what bugs went on it?
*nod*
Based on your other message elsewhere in the thread, I promise not to pull you or anyone else in QA under the bus, but I miiiight drag Jan Kurik with me as FPGM. Jan, what do you think about doing a Lightweight Critical Issues Review Meeting every, say, two weeks? We could start it with you and me and anyone else who wants to show up, and give it a hard limit of half an hour.
Adam, if we do that, would it be hard to add to the existing blockerbugs app, so we don't need to stand up new infrastructure?
Then we could try it for a bit and see if it is working / helpful or just another crazy idea.
On Mon, Oct 10, 2016 at 11:09 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Wed, Oct 05, 2016 at 02:33:37PM -0700, Adam Williamson wrote:
We used to have exactly this, up until Fedora 14. We had 'Target'
[much snip]
lighter process than the blocker review process, though I don't have a specific proposal for how that could look at this point in time. If it would mainly be used by the FPL and FPM, perhaps it could simply be the rule that they got to decide what bugs went on it?
*nod*
Based on your other message elsewhere in the thread, I promise not to pull you or anyone else in QA under the bus, but I miiiight drag Jan Kurik with me as FPGM. Jan, what do you think about doing a Lightweight Critical Issues Review Meeting every, say, two weeks? We could start it with you and me and anyone else who wants to show up, and give it a hard limit of half an hour.
Well, I did not jump into this discussion as I do not have a clear point of view on this topic. On one hand I see the benefit of having a list of prioritized bugs. On the other hand there were already such activities in the past (like the Target trackers described by Adam, or BugZappers with their Triage meetings) which disappeared over the time as ratio of the benefit to effort needed to maintain such a list was very low. Just for an information: on Fedora we have every week created approx. 400 - 500 new bugs. I can not imagine doing review of such an amount of bugs on (bi-)weekly basic. Blocker bug meeting typically takes 2-3 hours every week and the amount of proposed blockers is typically less than 10. Even on the Blocker bug meetings I see the need to check/consult an issue with a representative of a WG/SIG or a maintainer to fully understand what is really going on in the bug. With the amount of bugs Fedora receives I can not imagine doing the review without representatives from WGs and SIGs, just because of expertise needed to make a qualify decision. As such, the cost to have such a list of prioritized bugs is quite high and the benefit is questionable due to lack of enforcement.
[1] https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow
Regards, Jan
Adam, if we do that, would it be hard to add to the existing blockerbugs app, so we don't need to stand up new infrastructure?
Then we could try it for a bit and see if it is working / helpful or just another crazy idea.
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader
On Tue, Oct 11, 2016 at 03:29:37PM +0200, Jan Kurik wrote:
very low. Just for an information: on Fedora we have every week created approx. 400 - 500 new bugs. I can not imagine doing review of such an amount of bugs on (bi-)weekly basic. Blocker bug meeting
Oh my no. We wouldn't review all bugs, just ones which are nominated, and I am envisioning being quite strict with whether they meet the criterion I suggested:
Issues eligible for this status would be those which do not necessarily fail a release criterion but which have critical impact on a Fedora Edition or on a council-approved Fedora Objective.
with a possible additional:
Issues may also be nominated from the Common Bugs list when they are deemed by QA to have critical impact.
or something like that. If it becomes necessary, we could even restrict nominations to those submitted by QA, the Edition WGs, or Objective leads — but I'd rather start less formal and introduce that rule if it becomes a problem.
On Tue, Oct 11, 2016 at 3:51 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Tue, Oct 11, 2016 at 03:29:37PM +0200, Jan Kurik wrote:
very low. Just for an information: on Fedora we have every week created approx. 400 - 500 new bugs. I can not imagine doing review of such an amount of bugs on (bi-)weekly basic. Blocker bug meeting
Oh my no. We wouldn't review all bugs, just ones which are nominated, and I am envisioning being quite strict with whether they meet the criterion I suggested:
Issues eligible for this status would be those which do not necessarily fail a release criterion but which have critical impact on a Fedora Edition or on a council-approved Fedora Objective.
with a possible additional:
Issues may also be nominated from the Common Bugs list when they are deemed by QA to have critical impact.
or something like that. If it becomes necessary, we could even restrict nominations to those submitted by QA, the Edition WGs, or Objective leads — but I'd rather start less formal and introduce that rule if it becomes a problem.
Thinking of it ... lets start to think of a process/policy how this should work, to find possible frictions:
=Nomination= - Anyone can propose a bug as "Important". In case the number of nominated bugs will go over a limit we will be able to proceed during the approval process, we will limit the nomination possibility to a defined group of people. - The proposal will be done by a modified application QE currently use for Blocker bugs. - The bug is assigned to a tracker collecting the nominated bugs.
=Approval= - There will be (bi-)weekly meetings of a group of people doing a review of nominated bugs and granting approvals. - The group will be namely defined and needs quorum to approve a bug as "Important". - On the meeting, all the nominated bugs for the given period of time need to be reviewed. The review process might end up with the following statues: - - Approved: the bug is approved as "Important" and it moves from the nomination tracker to tracker for "Important" bugs - - Rejected: the bug has not been approved as "Important" and will be removed from the nomination tracker - - Postponed: the decision has not been made (i.e.: need more info). The bug stays on the nomination tracker till the next meeting
=Enforcement= - After every Approval meeting a wiki page with approved "Important" bugs will be generated (refreshed), to get people information what is important to fix. - We might integrate this bug list into http://whatcanidoforfedora.org/ page, so new comers can start to help in the area we consider as important - We might publish some stats in regular blogposts on https://communityblog.fedoraproject.org/ to have some overview which area/component needs an attention - We can grant badges once a developer fixes certain amount of "Important" bugs (something like https://badges.fedoraproject.org/badge/if-you-build-it...-koji-success-iii )
@Matt: does it reflect your thoughts ?
@All: does any one think this activity is meaningful ? If so, do you have any better proposal or would like to add something to the proposal above ?
Regards, Jan
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
I think your proposal is useful, and it should be tested how far it'll get us.
There's one more thing I'd like to be included. If approved, the bug should be categorized with respect to its impact on Fedora based on the discussion that led to its approval as "important". I think it would help to know why it is seen as important and what is at stake if it isn't fixed.
This info should be visible on the web page to help focussing the efforts to those bugs which may have the most impact.
On Wed, Oct 12, 2016 at 10:48:36AM +0200, Jan Kurik wrote:
@Matt: does it reflect your thoughts ?
Looks like a great place to start -- thanks. The one change I'd make is adding a separate "Critical" level, for things that will have us pacing the halls (figuratively) continually bugging people, pulling in favors, etc.
On Wed, Oct 12, 2016 at 9:38 AM, Matthew Miller mattdm@fedoraproject.org wrote:
On Wed, Oct 12, 2016 at 10:48:36AM +0200, Jan Kurik wrote:
@Matt: does it reflect your thoughts ?
Looks like a great place to start -- thanks. The one change I'd make is adding a separate "Critical" level, for things that will have us pacing the halls (figuratively) continually bugging people, pulling in favors, etc.
I agree Jan's proposal looks like a good idea. However, I can't but help notice that its necessity is driven almost entirely by the fact that we cannot use our existing bugzilla tool to do this job for us. All of the extra app stuff could be avoided if we disallowed reporters (or random people) to change the Severity and Priority fields.
josh
On Wed, 12 Oct 2016 09:55:40 -0400 Josh Boyer jwboyer@fedoraproject.org wrote:
On Wed, Oct 12, 2016 at 9:38 AM, Matthew Miller mattdm@fedoraproject.org wrote:
On Wed, Oct 12, 2016 at 10:48:36AM +0200, Jan Kurik wrote:
@Matt: does it reflect your thoughts ?
Looks like a great place to start -- thanks. The one change I'd make is adding a separate "Critical" level, for things that will have us pacing the halls (figuratively) continually bugging people, pulling in favors, etc.
I agree Jan's proposal looks like a good idea. However, I can't but help notice that its necessity is driven almost entirely by the fact that we cannot use our existing bugzilla tool to do this job for us. All of the extra app stuff could be avoided if we disallowed reporters (or random people) to change the Severity and Priority fields.
We could request this from bugzilla folks (restrict those fields to people in fedorabugs? Or should it be more restricted ?)
kevin
On Wed, Oct 12, 2016 at 01:13:05PM -0600, Kevin Fenzi wrote:
I agree Jan's proposal looks like a good idea. However, I can't but help notice that its necessity is driven almost entirely by the fact that we cannot use our existing bugzilla tool to do this job for us. All of the extra app stuff could be avoided if we disallowed reporters (or random people) to change the Severity and Priority fields.
We could request this from bugzilla folks (restrict those fields to people in fedorabugs? Or should it be more restricted ?)
To be useful for this purpose, it's gotta be super-restricted. I'm not sure if that will interfere with existing workflows.
Also, I think this only solves 10% of the problem (the "how do we indicate") part. It doesn't solve the workflow and acceptance part.
On Oct 12, 2016 4:15 PM, "Matthew Miller" mattdm@fedoraproject.org wrote:
On Wed, Oct 12, 2016 at 01:13:05PM -0600, Kevin Fenzi wrote:
I agree Jan's proposal looks like a good idea. However, I can't but help notice that its necessity is driven almost entirely by the fact that we cannot use our existing bugzilla tool to do this job for us. All of the extra app stuff could be avoided if we disallowed reporters (or random people) to change the Severity and Priority fields.
We could request this from bugzilla folks (restrict those fields to people in fedorabugs? Or should it be more restricted ?)
To be useful for this purpose, it's gotta be super-restricted. I'm not sure if that will interfere with existing workflows.
Also, I think this only solves 10% of the problem (the "how do we indicate") part. It doesn't solve the workflow and acceptance part.
True, but acceptance can be done in bugzilla too via tracker bugs. Workflow is similar either way; people review the issues in a tool.
To be clear, I'm not adamant we use bugzilla. I simply think it's odd to invest in yet another custom tool and service that Fedora infrastructure will now have to maintain and run. How many one off solutions do we need?
josh
On Wed, Oct 12, 2016 at 04:41:31PM -0400, Josh Boyer wrote:
To be clear, I'm not adamant we use bugzilla. I simply think it's odd to invest in yet another custom tool and service that Fedora infrastructure will now have to maintain and run. How many one off solutions do we need?
I was hoping we could just configure a corner of the blockerbugs app QA already uses rather than actually having a whole new one.
On Wed, 2016-10-12 at 16:41 -0400, Josh Boyer wrote:
On Oct 12, 2016 4:15 PM, "Matthew Miller" mattdm@fedoraproject.org wrote:
On Wed, Oct 12, 2016 at 01:13:05PM -0600, Kevin Fenzi wrote:
I agree Jan's proposal looks like a good idea. However, I can't but help notice that its necessity is driven almost entirely by the fact that we cannot use our existing bugzilla tool to do this job for us. All of the extra app stuff could be avoided if we disallowed reporters (or random people) to change the Severity and Priority fields.
We could request this from bugzilla folks (restrict those fields to people in fedorabugs? Or should it be more restricted ?)
To be useful for this purpose, it's gotta be super-restricted. I'm not sure if that will interfere with existing workflows.
Also, I think this only solves 10% of the problem (the "how do we indicate") part. It doesn't solve the workflow and acceptance part.
True, but acceptance can be done in bugzilla too via tracker bugs. Workflow is similar either way; people review the issues in a tool.
To be clear, I'm not adamant we use bugzilla. I simply think it's odd to invest in yet another custom tool and service that Fedora infrastructure will now have to maintain and run. How many one off solutions do we need?
For reference, we handled the blocker stuff entirely through Bugzilla for a while. We wrote blockerbugs for a few reasons. Ones I remember:
1. Since just looking at all bugs that block the 'blocker' tracker gives you both proposed and accepted blockers, you had to use a saved search or something to find just proposed blockers or just accepted blockers; blockerbugs handily groups them for you
2. None of Bugzilla's queries or anything gives you a handy view of what updates fix what blockers, while blockerbugs does
3. Bugzilla queries are (still) slow as hell (though not quite as bad as when we wrote blockerbugs). blockerbugs is fast (it has to run slow Bugzilla queries to sync its data, but it just syncs every half hour, so the user experience is fast)
On Wed, 2016-10-12 at 09:55 -0400, Josh Boyer wrote:
All of the extra app stuff could be avoided if we disallowed reporters (or random people) to change the Severity and Priority fields.
Mmm, I don't really think so. Presumably it would be maintainers who got to set those fields, right? But they are doing so in relation to *the package*. What's 'critical' for a given package is not necessarily 'critical' for the distribution. If there's a bug in 'some-obscure- package-two-people-use' that prevents it running, that bug should have maximum 'severity' (and probably 'priority'), but that still doesn't mean Matt or Jan would give a damn about it from a 'is the release on fire?' perspective.
On 13/10/16 10:37, Adam Williamson wrote:> 3. Bugzilla queries are (still) slow as hell (though not quite as bad
as when we wrote blockerbugs).
I haven't seen many bugs about this since the hardware upgrade. If something is slow please open a bug and we will look in to it.
It's hard to get time allocated for this kind of stuff without a list of bugs to put in front of management. Every performance bug we have open will give us more leverage to spend some time optimizing the query engine.
Cheers, Jeff.
On Thu, 2016-10-13 at 10:45 +1000, Jeff Fearn wrote:
On 13/10/16 10:37, Adam Williamson wrote:> 3. Bugzilla queries are (still) slow as hell (though not quite as bad
as when we wrote blockerbugs).
I haven't seen many bugs about this since the hardware upgrade. If something is slow please open a bug and we will look in to it.
It's hard to get time allocated for this kind of stuff without a list of bugs to put in front of management. Every performance bug we have open will give us more leverage to spend some time optimizing the query engine.
It's nothing out of the ordinary, it's just...I mean, it's doing a complex query of a gigantic database. Of course it won't be instantaneous. It's just nice with blockerbugs that you can just go to the URL and see the list right away.
On 13/10/16 13:59, Adam Williamson wrote:
On Thu, 2016-10-13 at 10:45 +1000, Jeff Fearn wrote:
On 13/10/16 10:37, Adam Williamson wrote:> 3. Bugzilla queries are (still) slow as hell (though not quite as bad
as when we wrote blockerbugs).
I haven't seen many bugs about this since the hardware upgrade. If something is slow please open a bug and we will look in to it.
It's hard to get time allocated for this kind of stuff without a list of bugs to put in front of management. Every performance bug we have open will give us more leverage to spend some time optimizing the query engine.
It's nothing out of the ordinary, it's just...I mean, it's doing a complex query of a gigantic database. Of course it won't be instantaneous. It's just nice with blockerbugs that you can just go to the URL and see the list right away.
:( But optimizing the query engine is more fun than fixing UI stuff...
Cheers, Jeff.
On Wed, Oct 12, 2016 at 8:33 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Wed, 2016-10-12 at 09:55 -0400, Josh Boyer wrote:
All of the extra app stuff could be avoided if we disallowed reporters (or random people) to change the Severity and Priority fields.
Mmm, I don't really think so. Presumably it would be maintainers who got to set those fields, right? But they are doing so in relation to
No, why would you presume that?
*the package*. What's 'critical' for a given package is not necessarily 'critical' for the distribution. If there's a bug in 'some-obscure- package-two-people-use' that prevents it running, that bug should have maximum 'severity' (and probably 'priority'), but that still doesn't mean Matt or Jan would give a damn about it from a 'is the release on fire?' perspective.
Right. Which speaks to Matt's "very restricted" list of people. Which would essentially be the same group that is going to do the categorizing anyway. Which means that since the fields are useless today (as in, completely) restricting them to useful to avoid another process or tool could be a possibility.
josh
On Wed, 2016-10-12 at 21:09 -0400, Josh Boyer wrote:
On Wed, Oct 12, 2016 at 8:33 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Wed, 2016-10-12 at 09:55 -0400, Josh Boyer wrote:
All of the extra app stuff could be avoided if we disallowed reporters (or random people) to change the Severity and Priority fields.
Mmm, I don't really think so. Presumably it would be maintainers who got to set those fields, right? But they are doing so in relation to
No, why would you presume that?
I dunno, just seemed logical. That's how they're intended to be used at present. Bug reporters aren't supposed to set them and don't have the privilege purely by rights of having an account...but because we grant 'editbugs' to all packagers and all QA team members, in practice a lot of the people who actually report bugs do have the power to set it.
If you're suggesting we restrict access to those fields such that even the packagers can't use them...well, it's a possibility, but I think at least *some* teams do actually use those fields at present, and would be inconvenienced by not being able to any more because we'd decided to take them over for distribution purposes.
Right. Which speaks to Matt's "very restricted" list of people. Which would essentially be the same group that is going to do the categorizing anyway. Which means that since the fields are useless today (as in, completely) restricting them to useful to avoid another process or tool could be a possibility.
Well sure, but on the other hand, if all you want to propose is 'do it all in Bugzilla', you don't really need to use those fields; just a tracking bug works fine. Or a whiteboard field. Or a flag. Anything searchable, really. blockerbugs is a convenience tool on top of the blocker process, it's not *necessary*. You *can* run the entire blocker process without it, and we used to do that.
On 13/10/16 14:02, Adam Williamson wrote:
On Wed, 2016-10-12 at 21:09 -0400, Josh Boyer wrote:
On Wed, Oct 12, 2016 at 8:33 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Wed, 2016-10-12 at 09:55 -0400, Josh Boyer wrote:
All of the extra app stuff could be avoided if we disallowed reporters (or random people) to change the Severity and Priority fields.
Mmm, I don't really think so. Presumably it would be maintainers who got to set those fields, right? But they are doing so in relation to
No, why would you presume that?
I dunno, just seemed logical. That's how they're intended to be used at present. Bug reporters aren't supposed to set them and don't have the privilege purely by rights of having an account
This is true for priority but not true for severity. Severity is the external, i.e. reporters, weighting of the bug and you do not need to be in editbugs to set it.
Cheers, Jeff.
On Thu, 2016-10-13 at 14:40 +1000, Jeff Fearn wrote:
On 13/10/16 14:02, Adam Williamson wrote:
On Wed, 2016-10-12 at 21:09 -0400, Josh Boyer wrote:
On Wed, Oct 12, 2016 at 8:33 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Wed, 2016-10-12 at 09:55 -0400, Josh Boyer wrote:
All of the extra app stuff could be avoided if we disallowed reporters (or random people) to change the Severity and Priority fields.
Mmm, I don't really think so. Presumably it would be maintainers who got to set those fields, right? But they are doing so in relation to
No, why would you presume that?
I dunno, just seemed logical. That's how they're intended to be used at present. Bug reporters aren't supposed to set them and don't have the privilege purely by rights of having an account
This is true for priority but not true for severity. Severity is the external, i.e. reporters, weighting of the bug and you do not need to be in editbugs to set it.
That's not the intent of the fields as I understand them. 'severity' is supposed to represent how bad the bug is, whereas 'priority' is supposed to represent how important it is to get it fixed compared to other bugs in the same component. They're obviously related, but not the same, and it's not "severity is the reporter's opinion, priority is the maintainers' opinion", no.
I think you might be right that we allow the bug reporter to set 'severity', though.
----- Original Message ----- | From: "Adam Williamson" adamwill@fedoraproject.org | To: "Development discussions related to Fedora" devel@lists.fedoraproject.org | Sent: Thursday, October 13, 2016 12:26:10 PM | Subject: Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one. | | On Thu, 2016-10-13 at 14:40 +1000, Jeff Fearn wrote: | > On 13/10/16 14:02, Adam Williamson wrote: | > > On Wed, 2016-10-12 at 21:09 -0400, Josh Boyer wrote: | > > > On Wed, Oct 12, 2016 at 8:33 PM, Adam Williamson | > > > adamwill@fedoraproject.org wrote: | > > > > On Wed, 2016-10-12 at 09:55 -0400, Josh Boyer wrote: | > > > > > All of the extra app stuff could be avoided if we disallowed | > > > > > reporters | > > > > > (or random people) to change the Severity and Priority fields. | > > > > | > > > > Mmm, I don't really think so. Presumably it would be maintainers who | > > > > got to set those fields, right? But they are doing so in relation to | > > > | > > > No, why would you presume that? | > > | > > I dunno, just seemed logical. That's how they're intended to be used at | > > present. Bug reporters aren't supposed to set them and don't have the | > > privilege purely by rights of having an account | > | > This is true for priority but not true for severity. Severity is the | > external, i.e. reporters, weighting | > of the bug and you do not need to be in editbugs to set it. | | That's not the intent of the fields as I understand them. 'severity' is | supposed to represent how bad the bug is, whereas 'priority' is | supposed to represent how important it is to get it fixed compared to | other bugs in the same component. They're obviously related, but not | the same, and it's not "severity is the reporter's opinion, priority is | the maintainers' opinion", no. | | I think you might be right that we allow the bug reporter to set | 'severity', though.
There is no direct relation between these fields. Many projects interpret in different ways, but the most common way is, 'severity' is what user thinks of the issue, how much of an issue it is for him ('user' is a QE engineer/consumer or a developer of other component). This is usually set to get the attention of the developer/owner of component over other bugs in same component. 'priority' is what the developer/owner of the component (owner of the bug) thinks its severity is. It can also be a consensus from all stake holders.
It is not uncommon to see high severity bugs getting triaged first. It is also a good practice to keep priority and severity at comparable, if not same level once triaged (i.e., it would not logically seem correct to see high severity with low priority or vice-versa after triage).
Regards, Sudhir
| -- | Adam Williamson | Fedora QA Community Monkey | IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net | http://www.happyassassin.net | _______________________________________________ | devel mailing list -- devel@lists.fedoraproject.org | To unsubscribe send an email to devel-leave@lists.fedoraproject.org |
On 13/10/2016 4:56 PM, Adam Williamson wrote:
On Thu, 2016-10-13 at 14:40 +1000, Jeff Fearn wrote:
On 13/10/16 14:02, Adam Williamson wrote:
On Wed, 2016-10-12 at 21:09 -0400, Josh Boyer wrote:
On Wed, Oct 12, 2016 at 8:33 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Wed, 2016-10-12 at 09:55 -0400, Josh Boyer wrote:
All of the extra app stuff could be avoided if we disallowed reporters (or random people) to change the Severity and Priority fields.
Mmm, I don't really think so. Presumably it would be maintainers who got to set those fields, right? But they are doing so in relation to
No, why would you presume that?
I dunno, just seemed logical. That's how they're intended to be used at present. Bug reporters aren't supposed to set them and don't have the privilege purely by rights of having an account
This is true for priority but not true for severity. Severity is the external, i.e. reporters, weighting of the bug and you do not need to be in editbugs to set it.
That's not the intent of the fields as I understand them. 'severity' is supposed to represent how bad the bug is, whereas 'priority' is supposed to represent how important it is to get it fixed compared to other bugs in the same component. They're obviously related, but not the same, and it's not "severity is the reporter's opinion, priority is the maintainers' opinion", no.
My understanding is based on ye olde services plan:
"Bugzilla Severity and Priority
When filing a new bug report, or actioning an existing bug, it is important to bear in mind that, while both the 'Severity' and 'Priority' fields are required; 'Priority' is an internal weighting and 'Severity' is customer weighting. This distinction can cause confusion if not consistant."
This is only significant in that it may have impacted the way they are coded on BRC.
I think you might be right that we allow the bug reporter to set 'severity', though.
BRC carries a custom patch to restrict priority to a group besides editbugs group (the setpriority group), AFAICT there is no code that allows similar restriction of the severity field.
Cheers, Jeff.
On Thu, 2016-10-13 at 19:33 +1000, Jeff Fearn wrote:
That's not the intent of the fields as I understand them. 'severity' is supposed to represent how bad the bug is, whereas 'priority' is supposed to represent how important it is to get it fixed compared to other bugs in the same component. They're obviously related, but not the same, and it's not "severity is the reporter's opinion, priority is the maintainers' opinion", no.
My understanding is based on ye olde services plan:
"Bugzilla Severity and Priority
When filing a new bug report, or actioning an existing bug, it is important to bear in mind that, while both the 'Severity' and 'Priority' fields are required; 'Priority' is an internal weighting and 'Severity' is customer weighting. This distinction can cause confusion if not consistant."
This is only significant in that it may have impacted the way they are coded on BRC.
I think you might be right that we allow the bug reporter to set 'severity', though.
BRC carries a custom patch to restrict priority to a group besides editbugs group (the setpriority group), AFAICT there is no code that allows similar restriction of the severity field.
Ah, interesting. I don't really have any particular source for my understanding of them, it's just something I've been carrying around for a while, I guess. However, Fedora definitely does not handle bugs the same as RHEL, so we're not necessarily *bound* by that definition...but we could use it if we liked.
On 14/10/2016 11:07 AM, Adam Williamson wrote:
On Thu, 2016-10-13 at 19:33 +1000, Jeff Fearn wrote:
That's not the intent of the fields as I understand them. 'severity' is supposed to represent how bad the bug is, whereas 'priority' is supposed to represent how important it is to get it fixed compared to other bugs in the same component. They're obviously related, but not the same, and it's not "severity is the reporter's opinion, priority is the maintainers' opinion", no.
My understanding is based on ye olde services plan:
"Bugzilla Severity and Priority
When filing a new bug report, or actioning an existing bug, it is important to bear in mind that, while both the 'Severity' and 'Priority' fields are required; 'Priority' is an internal weighting and 'Severity' is customer weighting. This distinction can cause confusion if not consistant."
This is only significant in that it may have impacted the way they are coded on BRC.
I think you might be right that we allow the bug reporter to set 'severity', though.
BRC carries a custom patch to restrict priority to a group besides editbugs group (the setpriority group), AFAICT there is no code that allows similar restriction of the severity field.
Ah, interesting. I don't really have any particular source for my understanding of them, it's just something I've been carrying around for a while, I guess. However, Fedora definitely does not handle bugs the same as RHEL, so we're not necessarily *bound* by that definition...but we could use it if we liked.
Hell no, but if a restriction on who can set severity was wanted we'd have to add a patch for that. Whereas for priority all you'd need is another BZ group and just switch the group inheritance.
Not that I think either of those fields are good for marking something as a blocker for the distribution, a blocker flag would be more useful for that IMO.
Cheers, Jeff.
On Fri, 2016-10-14 at 11:26 +1000, Jeff Fearn wrote:
Not that I think either of those fields are good for marking something as a blocker for the distribution, a blocker flag would be more useful for that IMO.
None of this is about the blocker process, we already have one of those and it works fine (it doesn't use flags, though that would work just as well as what we have).
Hi,
I drafted a process to cover the evaluation of "Important bugs" [1]. It still needs some work on the wording, however it should be good enough for review and comments. May I ask for a feedback and possibly improvement proposals, please ?
[1] https://fedoraproject.org/wiki/Fedora_Program_Management/Important_bugs_and_...
Thanks a lot, Jan
On Fri, Oct 14, 2016 at 3:29 AM, Adam Williamson adamwill@fedoraproject.org wrote:
On Fri, 2016-10-14 at 11:26 +1000, Jeff Fearn wrote:
Not that I think either of those fields are good for marking something as a blocker for the distribution, a blocker flag would be more useful for that IMO.
None of this is about the blocker process, we already have one of those and it works fine (it doesn't use flags, though that would work just as well as what we have). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On Wed, Nov 02, 2016 at 04:10:53PM +0100, Jan Kurik wrote:
I drafted a process to cover the evaluation of "Important bugs" [1]. It still needs some work on the wording, however it should be good enough for review and comments. May I ask for a feedback and possibly improvement proposals, please ?
[1] https://fedoraproject.org/wiki/Fedora_Program_Management/Important_bugs_and_...
This looks excellent to me as a first pass. We can adjust as need be as we go. I'm a little worried about sending the message that bugs that don't make the list here aren't "important" to us in a wider sense... maybe we want something more neutral like "Prioritized Issues"? I know this is a little bikesheddy, but it'll be hard to change later.
Also, I'd like to add the criteria:
Issues eligible for this status would be those which do not necessarily fail a release criterion but which have critical impact on a Fedora Edition or on a council-approved Fedora Objective. Issues may also be nominated from the Common Bugs list when they are deemed by QA to have critical impact.
to the page somewhere.
On Thu, Oct 13, 2016 at 12:02 AM, Adam Williamson adamwill@fedoraproject.org wrote:
On Wed, 2016-10-12 at 21:09 -0400, Josh Boyer wrote:
On Wed, Oct 12, 2016 at 8:33 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Wed, 2016-10-12 at 09:55 -0400, Josh Boyer wrote:
All of the extra app stuff could be avoided if we disallowed reporters (or random people) to change the Severity and Priority fields.
Mmm, I don't really think so. Presumably it would be maintainers who got to set those fields, right? But they are doing so in relation to
No, why would you presume that?
I dunno, just seemed logical. That's how they're intended to be used at present. Bug reporters aren't supposed to set them and don't have the privilege purely by rights of having an account...but because we grant 'editbugs' to all packagers and all QA team members, in practice a lot of the people who actually report bugs do have the power to set it.
If you're suggesting we restrict access to those fields such that even the packagers can't use them...well, it's a possibility, but I think at least *some* teams do actually use those fields at present, and would be inconvenienced by not being able to any more because we'd decided to take them over for distribution purposes.
Right. Which speaks to Matt's "very restricted" list of people. Which would essentially be the same group that is going to do the categorizing anyway. Which means that since the fields are useless today (as in, completely) restricting them to useful to avoid another process or tool could be a possibility.
Well sure, but on the other hand, if all you want to propose is 'do it all in Bugzilla', you don't really need to use those fields; just a
No. My main goal is "stop building one-off tools because existing tools (or usage of them) suck". If people want to enhance blockerbugs since it already exists, that's totally fine with me. Basically, I want us to stop wasting effort and creating more technical debt.
josh
On Thu, Oct 13, 2016 at 1:22 PM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Thu, Oct 13, 2016 at 12:02 AM, Adam Williamson adamwill@fedoraproject.org wrote:
On Wed, 2016-10-12 at 21:09 -0400, Josh Boyer wrote:
On Wed, Oct 12, 2016 at 8:33 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Wed, 2016-10-12 at 09:55 -0400, Josh Boyer wrote:
All of the extra app stuff could be avoided if we disallowed reporters (or random people) to change the Severity and Priority fields.
Mmm, I don't really think so. Presumably it would be maintainers who got to set those fields, right? But they are doing so in relation to
No, why would you presume that?
I dunno, just seemed logical. That's how they're intended to be used at present. Bug reporters aren't supposed to set them and don't have the privilege purely by rights of having an account...but because we grant 'editbugs' to all packagers and all QA team members, in practice a lot of the people who actually report bugs do have the power to set it.
If you're suggesting we restrict access to those fields such that even the packagers can't use them...well, it's a possibility, but I think at least *some* teams do actually use those fields at present, and would be inconvenienced by not being able to any more because we'd decided to take them over for distribution purposes.
Right. Which speaks to Matt's "very restricted" list of people. Which would essentially be the same group that is going to do the categorizing anyway. Which means that since the fields are useless today (as in, completely) restricting them to useful to avoid another process or tool could be a possibility.
Well sure, but on the other hand, if all you want to propose is 'do it all in Bugzilla', you don't really need to use those fields; just a
No. My main goal is "stop building one-off tools because existing tools (or usage of them) suck". If people want to enhance blockerbugs since it already exists, that's totally fine with me. Basically, I want us to stop wasting effort and creating more technical debt.
I am fine with using just Bugzilla for this purpose. It does not have fancy UI, but the capabilities for this job are sufficient. So, lets start with Bugzilla and we will see whether there will be a need for something more specific as we go.
I was also exploring a way how we can ensure the priority/severity fields will not be changed once the bug is tracked as "Important" by someone "non-authorized". My proposal is to use "PM Score" field instead. This is a hidden field, every bug has attached, and is not currently used for bugs in Fedora. The original purpose of this field is to prioritize bugs from the perspective of Product Management, so it in fact reflects what we are trying to achieve. The value of this field is numerical and is visible as a comment any time someone sets or changes its value. It is accessible via XML/RPC only.
Bugzilla has also a built-in tool called BRE (Bugzilla Rule Engine) which allow us to react on a change of a field and do some actions. So we might then enforce value of bug's priority according to the value sets in the PM Score field, if this will be useful.
Regards, Jan
josh _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Matthew Miller wrote:
I propose we create a parallel "Critical Issues" list, using basically the same procedures. Issues eligible for this status would be those which do not necessarily fail a release criterion but which have critical impact on a Fedora Edition or on a council-approved Fedora Objective.
Since Fedora is a volunteer process, this can't be backed by a hard mandate (like the "block the release!" emergency brake)
And that is exactly why this will never work. As you wrote in the subject, blocking the release is our only "big hammer". So, if we are not willing to block the release for such issues (and I really mean BLOCK, even if it takes weeks! Right now, blockers are very quickly downgraded or "resolved" by merely documenting them, which defeats the purpose of them being blockers), they will never get fixed.
Kevin Kofler
In theory, I like this idea.
In practice, Kevin Kofler is probably right. Unless there is a big hammer, bugs don't get fixed in many cases.
So I think the solution should be different: gfx team needs more manpower so they can handle bug reports. Right now, for some packages bugzilla serves as a dump of bugs nobody cares about. I doubt you can fix this by process or rules, I think fixing it by manpower will be more successful. As far as I can see those package maintainers do their job pretty well except for the fact that they don't have enough time to do so.