On Mon, 2011-11-07 at 04:19 -0500, Kamil Paral wrote: > > On Thu, 27 Oct 2011 07:59:12 -0400 (EDT) > > Kamil Paral <kparal@xxxxxxxxxx> wrote: > > > > > Quick question, > > > > > > how do rel-eng guys know which updates are OK to push to stable > > > during freeze and which are not? For example we have the final > > > freeze > > > now. Some packages like this: > > > https://admin.fedoraproject.org/updates/FEDORA-2011-14932 are > > > needed > > > to be pushed to stable repo, so they have an exception from the > > > freeze. Blocker and NTH updates have also exception from the > > > freeze. > > > But other packages may be also requesting push to stable and not be > > > eligible for an exception. How do the rel-eng guys know which > > > packages to push and which not to? > > > > QA files a ticket for each compose before it's made (ie, "we need > > another RC" or 'We need another TC'). In this ticket are listed the > > updates that are needed to be allowed into stable or used for the > > compose. > > > > So for example: > > > > https://fedorahosted.org/rel-eng/ticket/4951 > > > > kevin > > Thanks Kevin, > > now it's clear. This should probably be documented somewhere, but I'm not entirely sure where. The process is fairly simple, though. For raptor-proofing purposes: When to request the *initial* TC is on the release schedule. When to request further TCs is essentially a judgment call, there's no rule about it. Usually it's worth requesting one when there are significant changes in things like anaconda, kernel, lorax, plymouth etc compared to the previous TC. When to request the initial RC is also on the schedule, but there are specific rules about composing RCs: * They must happen after freeze (no image prior to freeze date can possibly be an RC) * They must address all accepted blocker bugs (no image which does not address an accepted blocker bug can possibly be an RC) So it's fairly straightforward to do RCs: you request the first one once the freeze has happened and all open blockers are addressed (usually this means fixes are available and have the necessary karma to go stable, but there are sometimes unusual blockers which get 'addressed' some other way - tell releng to block a certain package from compose, for e.g.). You can't request an RC if all open blockers are not yet addressed, even if it's 'due': you have to wait. You can, however, do a new TC build on the RC date if it looks like all blockers won't be fixed for a bit, but you want something out there for testing. You do subsequent RC composes if further blockers emerge in the first RC, and again, request them when fixes are available and push-able for all currently known blocker bugs. Note that you *can't* request an RC2 if RC1 turned out to have two blockers, and only one has been fixed so far. You have to have both new blockers fixed before spinning an RC2. In theory you could spin a TC *after* an RC in a case like this, and we came close to doing that for F16, but in the end we didn't, and never have. How you actually do a compose request is pretty simple: just go through the blocker list and list out all the updates that must be pulled into the compose to address all *accepted* blockers, and list any special instructions like 'make sure you use the latest spin-kickstarts' or 'block package XXX from the compose' or whatever. Also go through the NTH list and list any updates for *accepted* NTH bugs which have sufficient karma. List NTH and blocker updates separately. if you think of some other package that 'ought to' go in but isn't a fix for an nth or blocker bug, don't just list it anyway: propose it as an nth or blocker bug and get it voted in quickly by poking people on irc. always good to have the paperwork in order. trac syntax is horrible. for the record, to do a bullet list in trac, the format is: * bullet 1 * bullet 2 that's a space and then an asterisk. The space has to be there. For each 'release point' - Alpha, Beta, Final - there's *one* TC request ticket and *one* RC request ticket. rel-eng will close the ticket after TC1 or RC1 is done; if a TC2 / RC2 is to be requested, re-open the ticket to request it, it'll get closed again when that one's done, then you can re-open it for TC3/RC3, and so on. -- 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
