On Wed, 2019-07-24 at 10:04 -0400, pmkellly@xxxxxxxxxxxx wrote:
> I got feedback from Adam and Ben today; so the following changes have
> been made:
>
> I have added a little paragraph at the beginning to say what a last
> minute blocker bug is. I used freeze as the time anchor rather than a
> meeting since that seems to be the most firm time constraint we work to.
> Perhaps the review meetings could be anchored to the freeze as well.
> There might be some merit to showing the critical meetings in the
> schedule list that gets published.
>
> I changed "team" to "stakeholder groups"
>
> I removed "proposed" from places where it really didn't add anything.
>
>
> Have a Great Day!
>
> Pat (tablepc)
Thanks Pat! For future drafts, can you please just send them as plain
text in line? It makes it more convenient to read them quickly. For the
record, here is Pat's proposal:
" 3 Last Minute Blocker Bugs
3.1 A Last Minute Blocker Bug occurs when a bug is nominated
as a blocker bug seven (7) days or less before a scheduled freeze for
either a Beta or Final release
3.2 The stakeholder groups must agree according to the two
prior paragraphs in this section, that a Last Minute Blocker Bug has
the character of a Blocker Bug before being process per this section.
3.3 A Last Minute Blocker Bug shall be evaluated for being
delayed to the next release cycle according to the criteria below. A
Last Minute Blocker Bug that meets any of the listed criteria may be
delayed to the next release cycle as a Blocker Bug if the stakeholder
groups agree. Other Last Minute Blocker Bugs must be corrected before
the current cycle Final Release.
3.3.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.
3.3.2 Any bug in non-vital system operation or release
package installed application operation.
4 Delaying the current Release:
4.1 Delaying the current release cycle must take into account
all of the following criteria.
4.1.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?
4.1.2 Adding the current proposed delay to any prior
delays, is the total delay becoming unacceptable in regard to Fedora
release policy?
4.1.3 Will the current proposed delay enable other
desirable work to be completed for the release?
4.1.4 Impact on down stream projects."
I will follow up with a new draft of my own, as discussed at the
meeting last week.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
_______________________________________________
test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx
