----- Original Message -----
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
It features me being my typical wordy self, but I think it's not
*too*
long or eye-glazey and I hope it pretty comprehensively explains the
hows and whys of doing a compose request. Please review it and
provide
any feedback that occurs to you - factual, linguistical or otherwise.
Thanks! Note I tried to follow the vague Fedora convention with
regards
to 'must' and 'should' - 'must' is used specifically to mean
'this
absolutely must happen', 'should' is used to mean 'you really ought
to
do this but it's possible that in some weird cases there might be a
reason not to, I guess, and the world doesn't automatically end if
you
don't'.
I think it'd be a neat raptor-proofing test for someone else to do
the
F17 Beta or Final compose requests, maybe. Anyone feel like they want
to
get involved with that?
James, CCing you just in case you have any insights into the process
which have been lost on my bumbling watch. thanks!
Great to see this come together, thanks for the cc. The page looks great. It does a good
job of describing what a TC and RC are, and the "whys" for requesting them.
Perhaps I'm tired, but did I miss the "how" you actually request a compose?
Would it also make sense to document how you track the status of a request and the process
for listing known blocker and NTH package fixes?
Thanks,
James