Fwd: F13 Schedule Proposal--please RESPOND

[John Poelstra]

Bill Nottingham said the following on 11/03/2009 09:51 AM Pacific Time:
 > John Poelstra (poelstra at redhat.com) said:
 >>> John Poelstra (poelstra at redhat.com) said:
 >>>> I have had a Fedora 13 schedule drafted for several weeks based on the
 >>>> methodology we've established from previous releases.
 >>>> http://poelstra.fedorapeople.org/schedules/f-13/f-13-key-tasks.html
 >>> Just as a starting point, this schedule seems rather wrong; 
historically
 >>> the alpha/beta interim time is a month, roughly. You've scheduled
 >> Your comment that everything is "rather wrong" is not appreciated or
 >> a helpful way to start this discussion.
 >
 > Excuse me? I said the *schedule* seems rather wrong. I'm sorry if you
 > take offense to that, but it's not a personal judgement, and pulling it
 > out into some sort of statement about 'everything' seems a gross
 > overreaction.

Yes, you did not say "everything." I apologize for mis-characterizing 
what you said.

The schedule is something that I put a lot of time and thought and 
effort into. The general impression I get from your first responses to 
most of the new schedules I propose is that they are ill conceived and 
carelessly constructed. That gets old after a while.

In this particular case I started my message by saying I thought this 
schedule wasn't very good and was hoping that collectively we could 
create something better based on the historical analysis I had done.  It 
was disappointing not to have any of that acknowledged.

 >
 > If you'd prefer I just use words like 'bad', let me know.

My preference would be feedback on the exact parts of the schedule that 
you think should be changed with *specific dates* or durations that you 
think are better.  This is more constructive than grading the schedule 
as "wrong," "bad," "ugly," etc. :)  It can also save a lot of back and 
forth like we are having about the Alpha and Beta milestones (below).

 >
 >> 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.

 >
 >>> 6 weeks. It appears you're just adding the amounts we slipped this
 >>> release into the schedule at the points where we slipped this release.
 >> Incorrect assumptions.
 >>
 >>> If I was tweaking what you've had posted, beta moves one week later
 >>> relative to the final date, and alpha moves two, if not three weeks 
later.
 >> I'm following the methodology described here:
 >> https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle
 >
 > 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?

 From my view point there was nothing "new" to have publicly reviewed. 
I took as best as I could tell from the past release or two how long we 
scheduled for different tasks and created the wiki page and the Fedora 
13 schedule.  Based on how cramped the Fedora 12 schedule was around the 
final RC I added an exra week to the Beta Public Release so there could 
be a final Test Compose prior to the final RC.

My goal in writing down this methodology was to get to a more consistent 
place with how we do things so that other people can understand and be 
involved in the process.... and the general 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.

 >
 >>> ... how is 'work all done' something that's not already tracked?
 >> I was suggesting milestones for the Desktop team and that "work all
 >> done" was unclear to the desktop team this release.  It sounded like
 >> they planned to keep pushing changes in right up until the day of
 >> RC.
 >
 > '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.  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?

John