On Mon, Jul 17, 2017 at 05:48:09PM -0700, Adam Williamson wrote: > All such cases must be evaluated and discussed by the usual parties > (usually at a blocker bug review meeting) and all relevant factors must > be taken into account, much like the discussion of a bug that is a > 'conditional' violation of the release criteria. At least the following > will almost always be relevant: > > * The severity and likely prevalence of the bug > * Whether the bug could, or should, have been discovered earlier > * How long the release in question has already been delayed > * Whether delaying the release may give us an opportunity to carry out > other desirable work > * The possible effects of the expected delay (to Fedora itself, and > also to other things influenced by Fedora's schedules, including > downstream projects) For "could, or should, have been discovered earlier", there's also "raised as a blocker earlier". There were a couple this time around that actually had bugs filed but we didn't prioritize them until the last minute. Another consideration that might be relevant: is this a *new* issue or something that also affects the current release (either as released or with updates)? If something is a clear-cut blocker criterion violation but isn't a regression *and* we're running late, using further release delay as a forcing function feels like cutting off our nose to spite our face. -- Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> Fedora Project Leader _______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx