Hello, this was already been discussed a couple of years ago and the story can be found here: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/thread/Q46M75GUKRHMI5IMNGBNL6XHLD5GLLTS/
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 On Mon, May 13, 2019 at 5:27 PM pmkel...@frontier.com <pmkel...@frontier.com> wrote: > 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@lists.fedoraproject.org/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@lists.fedoraproject.org > To unsubscribe send an email to test-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > -- Lukáš Růžička FEDORA QE, RHCE Red Hat <https://www.redhat.com> Purkyňova 115 612 45 Brno - Královo Pole lruzi...@redhat.com TRIED AND PERSONALLY TESTED, ERGO TRUSTED. <https://redhat.com/trusted>
_______________________________________________ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
