Final karma requests

[Adam Williamson]

On Wed, 2013-06-26 at 15:10 -0300, Fernando Cassia wrote:
> On Wed, Jun 26, 2013 at 12:45 PM, Adam Williamson <awilliam at redhat.com> 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