On Thu, Nov 03, 2011 at 23:17:21 -0700,
Adam Williamson <awilliam(a)redhat.com> wrote:
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.
Yeah, I think early testing will be good there. (Unfortunately, that's
not an area I am good at helping with as I mostly do yum upgrades and
run rawhide/branched continuously rather than do lots of test installs.)
It might be useful to run through the test matrices at some other points in
the release cycle to get a heads up on potential blockers with more time
on them. It seemed this release we were in crisis mode for a lot of the
blockers.
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...
I am concerned with the process as executed not matching the documentation.
I'd just like to see a change codified that either allows moving the Go /
No-Go meeting when appropriate or just schedule it closer to the
readiness meeting.