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@xxxxxxxxxx +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
