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@xxxxxxxxxx> 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 -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
