On Mon, Jul 17, 2017 at 05:48:09PM -0700, Adam Williamson wrote:
> === 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.
+1
> 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 possibly be fixed within a reasonable time frame for the release to
> be made. For instance, fixing the bug may be a task of such technical
> complexity that it cannot possibly be achieved for several weeks or
> months, and it may be held that such a delay would be too disruptive to
> Fedora's development to be justified.
"cannot possibly" — that's pretty strong words. I sure almost anything
could be achieved in several months, if enough people banded up to do it.
So I'd just keep the first sentence, without "possibly", and drop the
rest of the paragraph. That'd cut down on the wordiness too.
> Secondly, it may occur if the bug is discovered 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 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)
>
> It is expected that in almost '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).
"almost" seems misplaced, or maybe you meant "almost all".
Zbyszek
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
