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! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
