On Fri, 2011-11-04 at 09:37 -0500, Bruno Wolff III wrote: > On Thu, Nov 03, 2011 at 23:17:21 -0700, > Adam Williamson <awilliam@xxxxxxxxxx> 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. We tried to do that to some extent in 16 cycle by moving the TC date one week up for both Beta and Final, and I think that worked pretty well. I also noted on the retrospective that we should avoid the trap of focusing too strongly on the blocker bugs we find _first_, and keep testing while those are getting fixed to find any others that are lurking. > > 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. Yup, indeed, bending process is a bad habit to get into. We can bring it up at the meeting and if everyone's happy with moving go/no-go back I can talk to Robyn and have the 17 schedule changed. -- 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
