Hello,
this was already been discussed a couple of years ago and the story can be found here:
I agree with how it is written, however, I sort of believe that this might be a rabbit hole opening if mistreated.
Therefore, as an addition to Adam's draft, I would suggest there be a quorum to make sure that the majority of stakeholders do really agree with the blocker bug waiver. Let's say, the decision would take at least ~10 people to vote, with the result of ~80 %, so that it is clear that we want it that way and the process cannot be misused to avoid bug fixing. Solid arguments would be needed to go over the quorum and I think that is reasonable.
Lukas
This is a resend.
In the last QA team meeting (04/29/2019) I volunteered to help with
adding something to the blocker bug process to handle Last Minute
Blocker Bugs.
I started by reading:
https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx/message/Q46M75GUKRHMI5IMNGBNL6XHLD5GLLTS/
Followed by: https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
and: https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
I agree that the provisions for how to handle last minute proposed
blocker bugs should be in the Blocker Bug Process rather than Blocker
Bug Meeting.
Here's my draft:
Exceptions for Last Minute Proposed Blocker Bugs
Last Minute Proposed Blocker Bugs must meet Blocker Bug Criteria before
being processed per this section.
Last Minute Blocker Bugs shall be evaluated for being delayed to the
next release cycle according to the criteria below. Last Minute Proposed
Blocker Bugs that meet any of the listed criteria may be delayed to the
next release cycle as Blocker Bugs if the Release Team agrees. Other
Last Minute Proposed Blocker Bugs must be corrected before the current
cycle Final Release.
1) Any bug that can not be fixed in a reasonable amount of time
considering the current Release Cycle or due to complexity or resource
constraints.
2) Any bug in non-vital system operation or release package installed
application operation.
Delaying the current Release:
Delaying the current release cycle must take into account all of the
following criteria.
1) Consider if the cause of the delay should have been caught earlier in
the current cycle. What changes in process could help moving such
discoveries earlier in the cycle?
2) Adding the current proposed delay to any prior delays, is the total
delay becoming unacceptable in regard to Fedora release policy?
3) Will the current proposed delay enable other desirable work to be
completed for the release?
4) Impact on down stream projects.
Looking forward to your feedback.
Have a Great Day!
Pat (tablepc)
_______________________________________________
test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx
--
Lukáš Růžička
FEDORA QE, RHCE
Purkyňova 115
612 45 Brno - Královo Pole
_______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx
