Fwd: F13 Schedule Proposal--please RESPOND

[Bill Nottingham]

Sorry about the delay - been drowning in F12 final hair-on-fire stuff.

John Poelstra (poelstra at redhat.com) said: 
> >> I'm not sure what period
> >> you believe should be a month.  Can you be more specific?
> >
> > The alpha/beta interim time; i.e., the time between corresponding
> > alpha and beta milestones.
> 
> Which alpha and beta milestones--Start/End of Alpha freeze? Alpha
> Public Release? Beta Freeze? Beta Public Release?  Specific date
> comparisons would be helpful.

The interim period between the alpha and beta public release is the
one that was most obvious to me. In every prior release except F-12
(because F-12 slipped), it's been right around a month. In your schedule,
it's set at 6 weeks. Hence my query as if you were just incorporating
the F-12 slip time.

If that's adjusted down to 4 weeks, the other related dates move a
similar amount. Alpha Release -> 2/23, Alpha Freeze -> 2/9, Feature
Freeze -> 2/1, Feature submission -> 1/19.

(As a random practical note, feature submission right after New
Years may not be best.)

> > If it's wrong, 'we should update the methodology'. You asked for feedback
> > on the schedule, not the methodology.
> >
> > Was this methodology ever posted in a FESCo or rel-eng meeting for public
> > review by the stakeholders? I don't recall it, but I could be wrong. So,
> > it really shouldn't be surprising that other people are surprised by the
> > output of this new methodology, when that output doesn't actually appear
> > to match what we've previously done.
> 
> Can you point out how what I've proposed in the Fedora 13 schedule
> is vastly different than Fedora 12?

On reflection, it's not that dissimilar from F-12 as it finished;
however, as above, I think part of it should be.

> concern around being eaten by raptors.  Hopefully it can also reduce
> the amount of discussion about future schedules because after 12
> releases we've finally figured out a few things that work best.
> 
> I am concerned that the Release Engineering team is not growing and
> new people do not come to our meetings or look for ways to get
> involved and help.  I thought it would help to create a better trail
> of documentation about our repeatable processes so that others can
> know how and why we do what we do.

No, more documentation is good; it just surprised me that it was all
in one place as a methodology, as that's not the sort of thing I'm
going to go randomly looking for if it's not pointed out.

One note as to the methodology as denoted on the spreadsheet - we
*do* need to define whether we are time-based with specific target
dates, or time-based with a specific length of cycle. If we are
time-based with specific target dates (May 1/Nov 1), tracking
'start -> <foo> milestone' durations, with 'start' being the actual
release date of the prior release, is meaningless to creating the
next schedule. If we're time based with 'a 6 month cycle, however
it lands', then those 'start -> milestone' durations become a
meaningful thing to track again.

> > 'work all done' is the RC freeze. Not all work is equal, though; there's
> > UI changes that affect collateral, rebases of fringe leaf node packages,
> >
> 
> It would seem to me that this isn't really working for us.  We
> haven't been able to compose an RC on time for the Alpha, Beta or
> Final. 

Part of this is a more strict handling of RCs. Before, we'd just
compose anyway, and not track the blocker list with such severity.
Now that we're actually treating the blocker list with a little more
process, we're slipping more.

> Is there any substance to the idea that if the "work"
> stopped just a little earlier (5-7 days) there might be more time
> for the developers to focus on the blockers so the RCs could be
> built in time and it wouldn't be such a last minute scramble?

That would just be moving the freeze date, wouldn't it? As a
counter-example, here in F-12 we've been frozen and just taking
fixes, and we still had blockers when it came time to compose the
RC.  I'm not sure that more freeze time would help here. Part of
me thinks that what would help the most is more attention to blockers
*throughout* the process.

Bill