On Wed, 2013-06-26 at 15:10 -0300, Fernando Cassia wrote: > On Wed, Jun 26, 2013 at 12:45 PM, Adam Williamson <awilliam@xxxxxxxxxx> wrote: > > Hi folks! We need karma on the following updates that are in Final RC2 > > and need to be pushed stable: > > > > https://admin.fedoraproject.org/updates/python-blivet-0.17-1.fc19,anaconda-19.30.12-1.fc19 (+1 this if install works...) > > https://admin.fedoraproject.org/updates/php-5.5.0-1.fc19 > > > > We also need karma on: > > > > https://admin.fedoraproject.org/updates/spin-kickstarts-0.19.7-1.fc19 > > > > as it needs to be pushed stable as part of the final release repos - > > just check that it matches the kickstarts used to build RC2. > > > > and finally it would help to get karma on: > > > > https://admin.fedoraproject.org/updates/liveusb-creator-3.11.8-3.fc19 > > Adam Williamson > > Fedora QA Community Monkey > > Adam, > > First let me apologize in advance in case this is a silly question. I > dont know the rules wrt the internal release process of the Fedora > team when code reaches RC status. Having said that... > > Is there a chance to get xorg-x11-server-Xorg-1.14.1-4.fc1 updated > with the upstream fix for its Xorg bug that causes F19's X server to > crash when running 32bit builds under Virtualbox? > > The details are at https://bugs.freedesktop.org/show_bug.cgi?id=59825 > and https://bugzilla.redhat.com/show_bug.cgi?id=972095#c1 > > ...it's ben marked as "high critical" by the Xorg team. > > The fix has been provided in the bug report and a user confirmed it > works w F19 beta > https://bugzilla.redhat.com/show_bug.cgi?id=972095#c1 > > If not, F19 will have the privilege of being the first Fedora release > that loses video when run under VBox (at least the 32bit builds of > F19). Unfortunately it's too late now, unless we discover some kind of late blocker which would cause a slip. Once we hit a freeze - which for F19 Final was on 06-18, the date is always on the schedule - only builds that fix bugs marked as AcceptedFreezeException or AcceptedBlocker will be taken into the release; everything else sits in u-t until the release is cut, then goes into 'updates', not the release repo. So if you want something to be fixed in the release images after the freeze, you _must_ nominate it as a blocker or freeze exception bug. Those who work closely on release validation kinda know this, but for everyone else, here's how it breaks down practically: The Go/No-Go meeting is always on a Thursday. Practically speaking, in the interest of sanity, the latest we can really build an RC and have it properly tested for the meeting is Tuesday night (NA time). We have pushed it to Wednesday before, esp. for Alphas and Betas that need less testing, and even done Thursday morning builds and crazy test sprints for particularly messy releases before. But really, especially for Final, Tuesday night is the cutoff we always have an eye on. The closer we get to that cut-off the less likely we are to want to mess with stuff. Once we hit the Monday of the go/no-go week, we're only really going to be putting freeze exception fixes in if they seem very important and very safe. This change may possibly have made RC1 if it had been acceptedFE and the update available at that time; I doubt we would have wanted to risk taking an Xorg change into RC2. So that's the practical schedule you want to be aware of in cases like this. Really, if there's an issue you really want to have fixed in a release, but it's not a blocker, you really want to have it nominated and accepted as an FE issue and a build available to fix it by at latest one week before go/no-go in order to be safe. If we slip a release on a Thursday, we usually kind of open an "FE window" for the first post-slip build on the Thursday and Friday to get in any FEs we really think are worth having fixed now we have that extra bit of building and testing time. But by Monday, for any builds that happen Monday night or later, we're mostly back in 'blocker fixes only' mode again. This isn't exactly stuff that gets written down in SOPs anywhere, it's more the kind of stuff that rapidly becomes apparent to you if you're actually an active part of getting releases rolled and tested: when you're one of the QA or releng folks sitting in IRC making the in-the-moment call of 'what packages should we pull in for this compose', the above is pretty much what you naturally gravitate towards. -- 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
