Re: Draft SOP for requesting TCs/RCs
On Thu, 2012-04-19 at 08:43 -0400, Kamil Paral wrote: > > We did have a few different bright ideas, but they're all rather > > bigger > > changes that might be better off being discussed separately from this > > SOP. > > > > So how about this: what if we put the current draft into production > > but > > entirely leave out the paragraph about doing a TC release after an RC > > release, so the SOP just doesn't cover the case at all? That would at > > least document current practice reasonably well. > > > > Then I'll try and find some time to synthesize all the ideas that > > came > > later in this thread, about revising TC/RC naming and so on, and > > maybe > > go back in time as well because I recall some similar proposals being > > made on devel a year or so back. I'll try and come up with some kind > > of > > comprehensive proposal covering all those ideas, in terms of actually > > revising the process itself. This SOP proposal was really just > > intended > > to be a document _describing_ current practice, I didn't have > > changing > > the practice in mind when writing it. > > > > If that sounds okay to everyone, I'll put the SOP minus the > > controversial paragraph into 'production' tomorrow, and then work on > > the > > new 'change the process' proposal when I can. Thanks! > > ACK OK, I went ahead and did this - https://fedoraproject.org/wiki/QA:SOP_compose_request . I'll try to come up with a synthesized proposal for improving the compose naming and so resolving the TC/RC problem ASAP (or of course, if anyone wants to get in first, they're more than welcome to!). Thanks for all the ideas everyone! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Draft SOP for requesting TCs/RCs
> We did have a few different bright ideas, but they're all rather > bigger > changes that might be better off being discussed separately from this > SOP. > > So how about this: what if we put the current draft into production > but > entirely leave out the paragraph about doing a TC release after an RC > release, so the SOP just doesn't cover the case at all? That would at > least document current practice reasonably well. > > Then I'll try and find some time to synthesize all the ideas that > came > later in this thread, about revising TC/RC naming and so on, and > maybe > go back in time as well because I recall some similar proposals being > made on devel a year or so back. I'll try and come up with some kind > of > comprehensive proposal covering all those ideas, in terms of actually > revising the process itself. This SOP proposal was really just > intended > to be a document _describing_ current practice, I didn't have > changing > the practice in mind when writing it. > > If that sounds okay to everyone, I'll put the SOP minus the > controversial paragraph into 'production' tomorrow, and then work on > the > new 'change the process' proposal when I can. Thanks! ACK -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Draft SOP for requesting TCs/RCs
On Wed, 2012-03-14 at 18:03 -0700, Adam Williamson wrote: > On Tue, 2012-03-13 at 06:04 -0400, Kamil Paral wrote: > > > 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. > > BTW, your line wrapping seems to be broken again :) > > Yeah, I'm not super happy with it either. I mainly just included it > because we nearly actually *did* it once. > > 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. I'm wondering if we > should simply leave this unaddressed in the SOP and deal with it on the > fly if the situation ever arises. I think perhaps we should give any > such build a label that's different from both TC and RC, if it ever > happens. > > Any bright ideas, anyone? We did have a few different bright ideas, but they're all rather bigger changes that might be better off being discussed separately from this SOP. So how about this: what if we put the current draft into production but entirely leave out the paragraph about doing a TC release after an RC release, so the SOP just doesn't cover the case at all? That would at least document current practice reasonably well. Then I'll try and find some time to synthesize all the ideas that came later in this thread, about revising TC/RC naming and so on, and maybe go back in time as well because I recall some similar proposals being made on devel a year or so back. I'll try and come up with some kind of comprehensive proposal covering all those ideas, in terms of actually revising the process itself. This SOP proposal was really just intended to be a document _describing_ current practice, I didn't have changing the practice in mind when writing it. If that sounds okay to everyone, I'll put the SOP minus the controversial paragraph into 'production' tomorrow, and then work on the new 'change the process' proposal when I can. Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Line wrapping (was Draft SOP for requesting TCs/RCs)
On Thu, 15 Mar 2012 16:01:31 -0400 (EDT) Kamil Paral wrote: ... > In this > case, at least for better behaving clients, if not the whole > line-reflow spec. For what it's worth, claws-mail handles the long lines gracefully, yet allows me to create auto-wrapped messages. I prefer auto-wrapping because I don't have to move my eyes and head so much to encompass the message. There is a pref setting to turn off auto-wrap, but I haven't tried it. The strange thing is that this type of wrapping is an html behavior, and claws-mail doesn't do html out of the box. There is a plugin to allow html, but I don't have it installed. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Line wrapping (was Draft SOP for requesting TCs/RCs)
> On Thu, 2012-03-15 at 12:28 -0400, Kamil Paral wrote: > > > Hmm, yeah. It's kind of a mess in this area, each tool working > > completely differently. > > This is one of the major reasons hard line-wrapping is still usually > recommended by experienced mail practitioners :) Current situation is a mess and therefore we have to adhere to the lowest common denominator just to be able to communicate. That's awful. The problem is that the situation doesn't improve, it's the same since stone age. It's because all the old-timers are fine with hard line-wrapping (I guess). Well I would rather force the tool authors to make the tools behave reasonable. Except that a lot of their developers are possibly old-timers. Hmm. But I suppose that could be solved in time. If you look at Gmail, it's an example how it can be done to "just work". I played with Evolution a bit. It has a very nice feature of auto-wrapping your text when composing it. If that was available in Zimbra, I would enable it just for the sake of Adam to be able to read my mail :-) Unfortunately it's not. I tried manually wrap all my messages in the past and it's goddamn tiresome. Every time I need to add a sentence to the middle and re-wrap all of the remaining lines I swear like hell. That's not an option. Also replacing Zimbra is not really an option, for many reasons. Adam complained that some messages display as a single line in Evolution. From my Evolution experiments it really seem not to allow to enable/disable line wrapping. But when I tried to create some plaintext draft without hard line-breaks, and then display it, it seemed to display it correctly (wrapping as needed). If it doesn't work for some emails, that seems like a bug to me, because Evolution can't possible expect all emails to be hard line-wrapped. It might be usual among OSS folks, but really among "general public". At least an option to enable/disable wrapping should be there (if it is not enabled by default). This whole situation is unfortunate and I'm sorry if my long lines are causing problems for some specific clients, but I don't really see a better option here than push for some better standard. In this case, at least for better behaving clients, if not the whole line-reflow spec. If you attach a bug report link against such a broken email client, I can promise to subscribe and support your case, it that helps at least a bit :-) -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Line wrapping (was Draft SOP for requesting TCs/RCs)
On Thu, 2012-03-15 at 12:28 -0400, Kamil Paral wrote: > Hmm, yeah. It's kind of a mess in this area, each tool working completely > differently. This is one of the major reasons hard line-wrapping is still usually recommended by experienced mail practitioners :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Draft SOP for requesting TCs/RCs
On Thu, 2012-03-15 at 07:29 -0500, Bruno Wolff III wrote: > On Thu, Mar 15, 2012 at 05:58:17 -0400, > Kamil Paral wrote: > > > BTW, your line wrapping seems to be broken again :) > > > > Hey, that's probably because I don't wrap lines. I see line wrapping as an > > end-client rendering feature, rather than manual source text formatting > > necessity. I know it breaks some tools (like Mailman web-view), but I see > > that more as a bug in those tools. We can discuss it in a separate thread. > > It's just that my technological heart bleeds every time I need to re-wrap > > someone's hard-wrapped lines. It's so damn 90's. > > You might want to set format=flowed though so that mail clients know it > is OK to wrap the lines when viewing the messages. Right. Evolution displays them as one big long line. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Line wrapping (was Draft SOP for requesting TCs/RCs)
Bruno Wolff III wrote: I use mutt and can set text_flowed in my .muttrc file. I have to remember to end lines with a space when I want them to be joinable. FWIW, if you use vim as your editor, you can use set fo=+w to help with that. -- ToddOpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~ Suppose I were a member of Congress, and suppose I were an idiot. But, I repeat myself. -- Mark Twain pgpkvhYlsJubV.pgp Description: PGP signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Line wrapping (was Draft SOP for requesting TCs/RCs)
> On Thu, Mar 15, 2012 at 09:11:06 -0400, >Kamil Paral wrote: > > > >Sorry, where exactly should I set this property? Is it some kind of > >an optional email header? Or is it an option in some popular email > >client? > > It's in the content-type header. For example: > Content-Type: text/plain; charset=us-ascii; format=flowed Thanks for info, it's interesting. I have found a pretty FAQ here: http://joeclark.org/ffaq.html I don't know whether I understood it correctly and I'm not sure it is the best technical solution, but at least it's some progress. > > >I am at the mercy of Zimbra that has exactly zero text wrapping > >options. (But I can't say I cared much until now, because it > >behaves properly in my view - it does not wrap lines when writing, > >but wraps it for reading.) > > I use mutt and can set text_flowed in my .muttrc file. I have to > remember > to end lines with a space when I want them to be joinable. > > We have zimbra at work (though I forward mail to my workstation) and > the > web interface doesn't display text/plain with format=flowed properly. > Hmm, yeah. It's kind of a mess in this area, each tool working completely differently. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Line wrapping (was Draft SOP for requesting TCs/RCs)
On Thu, Mar 15, 2012 at 09:11:06 -0400, Kamil Paral wrote: Sorry, where exactly should I set this property? Is it some kind of an optional email header? Or is it an option in some popular email client? It's in the content-type header. For example: Content-Type: text/plain; charset=us-ascii; format=flowed I am at the mercy of Zimbra that has exactly zero text wrapping options. (But I can't say I cared much until now, because it behaves properly in my view - it does not wrap lines when writing, but wraps it for reading.) I use mutt and can set text_flowed in my .muttrc file. I have to remember to end lines with a space when I want them to be joinable. We have zimbra at work (though I forward mail to my workstation) and the web interface doesn't display text/plain with format=flowed properly. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Line wrapping (was Draft SOP for requesting TCs/RCs)
> On Thu, Mar 15, 2012 at 05:58:17 -0400, > Kamil Paral wrote: > > > BTW, your line wrapping seems to be broken again :) > > > > Hey, that's probably because I don't wrap lines. I see line > > wrapping as an end-client rendering feature, rather than manual > > source text formatting necessity. I know it breaks some tools > > (like Mailman web-view), but I see that more as a bug in those > > tools. We can discuss it in a separate thread. It's just that my > > technological heart bleeds every time I need to re-wrap someone's > > hard-wrapped lines. It's so damn 90's. > > You might want to set format=flowed though so that mail clients know > it > is OK to wrap the lines when viewing the messages. > Sorry, where exactly should I set this property? Is it some kind of an optional email header? Or is it an option in some popular email client? I am at the mercy of Zimbra that has exactly zero text wrapping options. (But I can't say I cared much until now, because it behaves properly in my view - it does not wrap lines when writing, but wraps it for reading.) -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Draft SOP for requesting TCs/RCs
On Thu, Mar 15, 2012 at 05:58:17 -0400, Kamil Paral wrote: > > BTW, your line wrapping seems to be broken again :) > > Hey, that's probably because I don't wrap lines. I see line wrapping as an > end-client rendering feature, rather than manual source text formatting > necessity. I know it breaks some tools (like Mailman web-view), but I see > that more as a bug in those tools. We can discuss it in a separate thread. > It's just that my technological heart bleeds every time I need to re-wrap > someone's hard-wrapped lines. It's so damn 90's. You might want to set format=flowed though so that mail clients know it is OK to wrap the lines when viewing the messages. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Draft SOP for requesting TCs/RCs
> BTW, your line wrapping seems to be broken again :) Hey, that's probably because I don't wrap lines. I see line wrapping as an end-client rendering feature, rather than manual source text formatting necessity. I know it breaks some tools (like Mailman web-view), but I see that more as a bug in those tools. We can discuss it in a separate thread. It's just that my technological heart bleeds every time I need to re-wrap someone's hard-wrapped lines. It's so damn 90's. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Draft SOP for requesting TCs/RCs
> Does the distinction between TC and RC need to be in the name? How > about > > C1 < C2 < C3 ... > > with possibly an "R" suffix if the number of blocker bugs is 0, like > > C1 < C2 < C3R < ... > > This way they're alphabetical. There are also other side effects of > the > distinction between TC and RC such as having two separate releng > tickets, two > separate categories in the wiki, etc. and maybe some of those are > unnecessary as > well. I was about to propose exactly the same: build 1 < build 2 < build 3 RC < build 4 < build 5 RC How we actually name the builds is a small detail (e.g. B1, B2, B3.RC), but it is alphabetic and we can have much more builds this way if we need it without making things more complicated. We mark some builds/composes as RC if it satisfies the criterion. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Draft SOP for requesting TCs/RCs
Eric Blake redhat.com> writes: > 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. Does the distinction between TC and RC need to be in the name? How about C1 < C2 < C3 ... with possibly an "R" suffix if the number of blocker bugs is 0, like C1 < C2 < C3R < ... This way they're alphabetical. There are also other side effects of the distinction between TC and RC such as having two separate releng tickets, two separate categories in the wiki, etc. and maybe some of those are unnecessary as well. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Draft SOP for requesting TCs/RCs
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 ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Draft SOP for requesting TCs/RCs
On Tue, 2012-03-13 at 06:04 -0400, Kamil Paral wrote: > 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. BTW, your line wrapping seems to be broken again :) Yeah, I'm not super happy with it either. I mainly just included it because we nearly actually *did* it once. 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. I'm wondering if we should simply leave this unaddressed in the SOP and deal with it on the fly if the situation ever arises. I think perhaps we should give any such build a label that's different from both TC and RC, if it ever happens. Any bright ideas, anyone? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Draft SOP for requesting TCs/RCs
On Tue, 2012-03-13 at 22:51 -0400, James Laska wrote: > - Original Message - > > On Tue, 2012-03-13 at 22:29 -0400, James Laska wrote: > > > > > 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? > > > > Did you see the section named "How to request a compose"? > > Heh apologies, after clicking submit on my section edit ... I now see the > full document. > > It certainly seemed out of character for your material, so I'm not > surprised to find it was already there :) Hehe, no problem - experience has taught me it's always a good idea to triple-check that everyone's on the same page =) thanks for the review. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Draft SOP for requesting TCs/RCs
- Original Message - > On Tue, 2012-03-13 at 22:29 -0400, James Laska wrote: > > > 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? > > Did you see the section named "How to request a compose"? Heh apologies, after clicking submit on my section edit ... I now see the full document. It certainly seemed out of character for your material, so I'm not surprised to find it was already there :) > > 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? > > I'm pretty sure I did the latter: see "Explicitly listing required > builds" and "What builds to ensure are included". I didn't do the > former...it's not *precisely* in the scope of the SOP but it may make > sense. I'll think about it. Thanks, James -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Draft SOP for requesting TCs/RCs
On Tue, 2012-03-13 at 22:29 -0400, James Laska wrote: > 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? Did you see the section named "How to 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? I'm pretty sure I did the latter: see "Explicitly listing required builds" and "What builds to ensure are included". I didn't do the former...it's not *precisely* in the scope of the SOP but it may make sense. I'll think about it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Draft SOP for requesting TCs/RCs
- 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 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Draft SOP for requesting TCs/RCs
> 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. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Draft SOP for requesting TCs/RCs
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@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
