[Test-Announce] Fedora 16 Final Release Declared GOLD!

[Adam Williamson]

On Thu, 2011-11-03 at 23:23 -0500, Bruno Wolff III wrote:
> On Thu, Nov 03, 2011 at 15:56:49 -0700,
>   Adam Williamson <awilliam at redhat.com> wrote:
> > 
> > I'd certainly second Robyn's thanks to all the awesome folks on the
> > devel, releng and QA teams who worked so hard to get this thing done and
> > shiny without slipping any further. We bent process a little to make the
> > release date but we didn't compromise on quality at all, which is great.
> 
> Hopefully we'll try to figure out why so much heroic effort was needed
> to keep from slipping any further than we did. That kind of thing tends
> to burn people out and we don't want it happen regularly.

I think it boils down almost entirely to the big behaviour changes in
anaconda in F16, which unfortunately suggests F17 may also be a tricky
cycle, with the UI rewrite (and possible btrfs adoption). anaconda
provides a disproportionately high number of blockers, and the
bootloader and disk label changes in F16 caused change (and hence bugs,
change _always_ means bugs) in lots of paths we've simply not had to
worry about for a long time. All the issues with bootloader installation
on upgrade, BIOS boot partitions and so on are quite simply things we've
never previously had to deal with at all.

This didn't just cause _more_ bugs it caused bugs which were more
difficult to handle and test, because they weren't just 'hey, function X
doesn't work any more' but 'uh, now we're doing A, B and C differently,
our assumptions about D, E and F turn out to be wrong - what the heck do
we do about that?', which is a much more complex issue.

I hope this doesn't offend anyone from the anaconda team, but I do kind
of get the sense that perhaps all the implications of the changes
weren't planned out ahead of time; there seemed to be a lot of making it
up as we went along. The UI rewrite seems to be getting a lot of
pre-planning and whiteboarding and so on, so I'm vaguely hopeful that
they'll catch more of the pitfalls in advance, with that.

It'd be great if we can work with the anaconda team closely to try and
get involved all along the line in the UI rewrite stuff, and see if that
can reduce the pressure around release times - let's put that on the
table for the next meeting. But it might still turn out to be a tough
one. If anyone has any suggestions or ideas at all, please do contribute
them! The more thinking the better.

> We also fudged the Go / No-Go meeting twice. We should either accomadate
> this in thge process documentation or stop doing it.

Yeah, agreed. I don't think there's any especial need for the go/no-go
to be an entire day ahead of the release readiness meeting, in all
honesty - it seems to work fine simply to do it earlier the same day. So
do you think it'd be alright to suggest that as a change for the F17 and
beyond scheduling? Every time we've decided the delay the go/no-go
decision, that choice in itself hasn't caused any problems, as far as
I'm aware. It simply gives us more time for validation, which is never a
bad thing...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net