On Wed, 2012-03-14 at 18:03 -0700, Adam Williamson wrote: > 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? We did have a few different bright ideas, but they're all rather bigger changes that might be better off being discussed separately from this SOP. So how about this: what if we put the current draft into production but entirely leave out the paragraph about doing a TC release after an RC release, so the SOP just doesn't cover the case at all? That would at least document current practice reasonably well. Then I'll try and find some time to synthesize all the ideas that came later in this thread, about revising TC/RC naming and so on, and maybe go back in time as well because I recall some similar proposals being made on devel a year or so back. I'll try and come up with some kind of comprehensive proposal covering all those ideas, in terms of actually revising the process itself. This SOP proposal was really just intended to be a document _describing_ current practice, I didn't have changing the practice in mind when writing it. If that sounds okay to everyone, I'll put the SOP minus the controversial paragraph into 'production' tomorrow, and then work on the new 'change the process' proposal when I can. Thanks! -- 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
