On Wed, Oct 10, 2012 at 12:17:41 -0400, David Cantrell <dcantrell@xxxxxxxxxx> wrote:
You're not understanding what I was pointing out. The blocker criteria between alpha and beta should be more open than the blocker criteria between beta and rc. The idea is that we start accepting fewer bugs as blockers as we get closer to RC. Every problem encountered can be evaluated along the lines of:
The point of accepting fewer things as blockers for alpha and beta is to enable those to be released to help find bugs. And we don't want to hold them up for things that are not things we want final to have, but that don't interfere with testing too much.
1) Who is impacted? 2) Is there a workaround? 3) Is the workaround documented? 4) Is the problem in the standard install path? And so on. I'm not saying we should compromise on release quality or anything like that, but just start to ask more and more questions when proposed blockers show up late. Is it really a blocker or not.
I disagree that we want to look at lateness as a critera for blockers. (It does get some consideration for the nice to have designation.) I think the kinds of bugs that lateness would be a consideration for, are not the kinds of bugs we want to classify as blockers.
_______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
