Draft SOP for requesting TCs/RCs

[Eric Blake]

On 03/14/2012 07:03 PM, Adam Williamson wrote:
>>
>> 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.
> 

> 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.

What about requiring the number to be strictly increasing:

TC1 < RC2 < RC3 < TC4 < RC5

where the prefix denotes how stable we think this particular build is (T
vs. R depending on whether there are known blockers).  Since you don't
reuse the suffix, it becomes immediately apparent whether the iso you
are testing came before or after another iso.  Of course, someone will
then ask why we have RC2 but not RC1, but that's hopefully an easier
question to answer.

-- 
Eric Blake   eblake at redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/test/attachments/20120314/a50dd913/attachment.sig>