On Tue, 2012-03-13 at 06:04 -0400, Kamil Paral wrote: > One remark to this paragraph: > > > It is theoretically possible that the situation could arise where > > a release candidate is requested and built, and results in multiple > > blockers being reported and accepted, some of which are easy to fix and > > some of which are not; in this case a subsequent compose to test the easy > > fixes may be desirable, but could not be denoted a release candidate due > > to the presence of the other un-addressed blockers. In this case a new > > test compose could be requested. This is obviously somewhat confusing, > > however, so it is best to try and get all the blockers fixed and request > > a new release candidate instead. > > I don't believe this is a good idea. I would rather have QA team vote > on "exceptional circumstances" and call it another RC. There's no > point in calling it TC just to satisfy some criteria. > > TC and RC naming is confusing already. RC > TC, but not > alphabetically. Having e.g. TC1 < RC1 < RC2 < TC2 < RC3 is a complete > mess, arcane knowledge that only QA team would have. Since we > generally ask also other parties to perform testing, we should have > the naming pattern as obvious and straightforward as possible. Let's > call it RC and lets clearly state that this is an exceptional process > that should happen just rarely. BTW, your line wrapping seems to be broken again :) Yeah, I'm not super happy with it either. I mainly just included it because we nearly actually *did* it once. The thing is, I'm not really happy with the alternative you suggest (calling it an RC) either. I really think it's a good thing to stick to a strict definition, and a release candidate, strictly, is a build you believe can be the release. A build which is known to include a blocker simply is not a release candidate. It could not possibly be released. So I'd love if we could come up with a third way. I'm wondering if we should simply leave this unaddressed in the SOP and deal with it on the fly if the situation ever arises. I think perhaps we should give any such build a label that's different from both TC and RC, if it ever happens. Any bright ideas, anyone? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
