On Thu, Aug 10, 2017 at 3:01 AM, Adam Williamson <[email protected] > 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 > https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process , 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. > LGTM > > 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). > I wonder if we should provide a recommendation here - whether to target the next milestone, or the equivalent milestone by default. Otherwise we spend time discussing this each time (as we did during F26 cycle). I think the more correct approach is to target the equivalent milestone. But it also has higher demands on our team - we can't simply rely on the dev team remembering this very important bug, otherwise we might find ourselves at the very same situation for FN+1 Final milestone, just because the dev team forgot about it. So we need to remind them and ask for status regularly. There is more area for error when targeting the next milestone (even if we found out the dev team forgot about it for Beta and we failed to remind them, there's still some time until Final), but it's slightly more unfair to the dev team (the compose might not originally require the bugfix to be present at such early milestone). So, to save these discussions from re-occurring, maybe we could "pre-compute" the recommended approach? :)
_______________________________________________ test mailing list -- [email protected] To unsubscribe send an email to [email protected]
