Thanks Adam for putting this together. I am definitely+1 to extend the
Blocker bug process with your proposal.

And there is one more topic related to this: how we should deal with
0day bugs found at the last moment before release ? Should not we have
a statement for Accepted0Day and AcceptedPreviousRelease blockers
saying that such bugs need to be verified and have enough karma before
relevant Go/No-Go meeting ? My question is base on the experience we
made during F26 release cycle, when we stopped already running
mirroring of a release as we realized the 0day fix will not be ready
at the release day. Having such a statement (and follow it) might save
the effort especially RelEng is putting into the release activities
after Go/No-Go meeting.


On Thu, Aug 10, 2017 at 3:01 AM, Adam Williamson
<> wrote:
> On Mon, 2017-07-17 at 17:48 -0700, Adam Williamson wrote:
>> Hi, folks!
> <snip>
> So there was some great feedback on the first version of this proposal;
> here's the second draft, with all the suggestions considered and
> applied. Note, given the misunderstanding between Kamil and Matt, I
> added a little paragraph to specifically clarify that the list of
> factors to consider really is just a list of things to *consider*, not
> a checklist of criteria that we apply unthinkingly.
> As I explained in the first mail, the proposal is to add a section to
> , called
> "Exceptional cases", as a sub-section of the 'Reviewing blocker bugs'
> section. Here is the revised proposal for how the new section should
> read:
> ##################
> === Exceptional cases ===
> Generally speaking, any bug that is agreed to be a violation of the
> [[Fedora Release Criteria|release criteria]] should be accepted as a
> blocker bug for the next relevant milestone release.
> However, as explained in the [[Fedora_Release_Life_Cycle|Fedora life
> cycle page]] and the
> [[Fedora_Release_Criteria#Release_Constraints|release criteria]], we
> consider Fedora's release process not to be strictly based on time
> ''or'' strictly based on quality, but to take both into consideration.
> This can mean that, in some exceptional circumstances, we may agree
> that a bug constitutes a sufficient violation of the release criteria
> that it would ordinarily be accepted as a blocker bug for the next
> milestone release, but in fact accept it as a blocker bug for a later
> milestone release.
> There are currently two established circumstances in which this may
> occur.
> Firstly, it may occur if it is agreed to be very unlikely that the bug
> can be fixed within a reasonable time frame for the release to
> be made.
> Secondly, it may occur if the bug is discovered and/or proposed as a
> blocker very late in the release validation process. Sometimes, a
> relatively less important blocker bug (such as a non-vital default
> installed application on a release-blocking medium failing to run, for
> instance) may only be found very near the end of the release validation
> process, too late for it to be reasonably possible to fix it without
> delaying the release. Again, we may make the determination that in such
> a case it is preferable to go ahead with the release rather than delay
> it to fix such a late-discovered bug.
> 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 and/or
> proposed as a blocker earlier
> * Whether the bug affects the existing stable releases (if it does,
> there is generally less benefit to be had by delaying the new release)
> * 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)
> Note that these factors should be carefully and intelligently
> considered on a case-by-case basis. This isn't a checklist; we cannot
> just say "oh, that bug existed in the previous release, therefore it's
> not a blocker, done". It's just a list of some of the factors we
> typically ''consider'' in making this determination.
> It is expected that in almost all 'exceptional' cases, the bug will be
> accepted as a blocker either for the very next milestone release, or
> for the equivalent milestone for the next release (e.g. if this
> 'exceptional' provision is agreed to apply to a bug that otherwise
> would have blocked {{FedoraVersion|long|next}} Final, it should be
> accepted as a blocker either for {{FedoraVersion|long|next2}} Alpha or
> {{FedoraVersion|long|next2}} Final).
> #################
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | adamwfedora
> _______________________________________________
> devel mailing list --
> To unsubscribe send an email to

Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
devel mailing list --
To unsubscribe send an email to

Reply via email to