Draft SOP for requesting TCs/RCs

[Kamil Paral]

> Hey, folks.
> 
> So I've been doing the TC / RC requests for a while, and James did
> them
> before that. It occurred to me that while it's theoretically
> 'obvious'
> how this happens, and mostly defined by the release validation
> process,
> in practice it's probably worth having an explicit SOP to describe
> how
> to do this, for raptor-proofing purposes.
> 
> I wrote a kind of proto-SOP to the list back last year:
> 
> https://lists.fedoraproject.org/pipermail/test/2011-November/104402.html
> 
> so I just expanded that out into this draft formal SOP:
> 
> https://fedoraproject.org/wiki/User:Adamwill/Draft_QA_SOP_compose_request

Kudos for creating this. I understand the process better now.

It is well readable and clear.

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.