Draft SOP for requesting TCs/RCs

[Adam Williamson]

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