On Wed, 2009-07-08 at 17:00 -0700, John Poelstra wrote: > o Added earlier blocker review days (f13) > o Changed usage of "Release Candidate" (f13) > o Fixed dates for Beta phase so that "to" and "from" dates are > correct > in the context of the report (notting) > > http://poelstra.fedorapeople.org/schedules/f-12/f-12-releng-tasks.html > > Hopefully this version is a good starting point for the meeting f13 > said > he would arrange with QA at Monday's meeting. > Hrm, something is still missing. Here is the feedback that I gave James. Blocker Reviews) we need a blocker review day to happen with enough time for maintainers to react and fix things prior to the freeze. I see there are ones scheduled for the 17th, 24th, and 31st, with the freeze being Aug 4th. This is good, but is there a good reason to have 3 before the freeze, rather than 2? Just curious. Also curious (and forgetful) what the reason is we are doing these on Fridays. What's missing here is a review of the blocker bugs just before the RC compose (is this implicit?) as well as one /after/ the RC compose and testing. Test Composes) Releng would like to provide QA with at least one test compose with enough time for QA to test and provide feedback prior to the freeze. This will help us and maintainers know what is broken and needs fixing, saving nasty surprises and slips once we actually do freeze. On the current schedule I do not see any scheduled compose prior to the freeze. This means that the first time we'd have an opportunity to test full media installs and reduced package sets, etc.. is after we've frozen and when we're under extreme time pressure to get the release out. High potential for slippage when operating this way. Release Candidate) Releng would like there to be only one scheduled release candidate. It is difficult to schedule because we cannot create an RC until the blocker list is clear, see above needing a blocker list review just prior to RC compose date. Looking at Alpha, RC compose date should probably be the 6th or 7th, to give QA enough time to test it and to have a chance at second RC if necessary on the 10th or 11th. To have RC compose on the 6th, we'll need blocker review either on the 6th morning, or 5th evening. Either we're clear and can compose RC, or we're not clear and we have to delay RC. We'll need another blocker review on the 10th evening or 11th morning. Either we're clear and we publish the previous RC, or there were new things picked up that need to be fixed and we get another RC, or there are too many things to fix and we slip. I feel strongly that we shouldn't actually schedule a second RC. That just gives too much to the perception that things can wait until the second RC to be fixed. A second RC should be a disaster to be avoided, not a constant to be assumed. However I do think we should setup the schedule to leave room for a second RC without a slip, should we need it. James, does this accurately describe what we discussed earlier? -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
