12:30 p.m.
-------- Original Message --------
Subject: F13 Schedule Proposal--please RESPOND
Date: Fri, 30 Oct 2009 10:28:42 -0700
From: John Poelstra <poelstra(a)redhat.com>
To: rel-eng(a)fedoraproject.org
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
I'm reluctant to publish this Fedora 13 draft because I think we can
come up with something better. This thinking came out of a spreadsheet
I built to calculate the actual number of days between the significant
milestones in each of our schedules since Fedora 8 (see attached). Some
of the comparisons between releases are surprising. Others lead me to
believe we are making adjustments in the wrong places.
One of the biggest issues this analysis shows is that because we insist
on setting our next targeted release to Halloween or May Day we short
change the next release when we slip the release under development. For
example, Fedora 12 slipped by two weeks + one additional week added for
conference attendance. This takes three weeks away from Fedora 13 and
results in a 5.25 month release cycle.
Questions:
1) Are we truly getting value out of the "Halloween/May Day" principle?
2) Desktop has said they could use more time to do polish, etc. How much
longer would they propose? My question on fedora-desktop-list went
unanswered.
3) With the advent of the test days and ISOs for those events, are we
getting any value out of the weekly snapshots during Alpha? Should we
keep doing them?
My proposal:
1) Move to a solid 6 month release cycle--add 6 months to GA date of
previous release with the exception that adjustments will be made
when/if this collides with December holidays. I realize this could mess
up synchronization with the Gnome schedule.
2) Eliminate weekly snapshots during Alpha since their value is questionable
3) Set the alpha and beta public testing durations to three weeks each.
4) Add new milestones for Desktop freezes, polish, and "work all done."
Please get back to me by Wednesday, November 4, 2009.
Thanks,
John
12:49 p.m.
John Poelstra (poelstra(a)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
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.
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.
Questions:
1) Are we truly getting value out of the "Halloween/May Day" principle?
We are getting value of having a predictable release, IMO. If we want
to shift that slightly, we can, but I don't think moving to a cycle
where each slip slides all subsequent releases that same amount really
helps; we end up releasing at a semi-random time each year.
3) With the advent of the test days and ISOs for those events, are
we
getting any value out of the weekly snapshots during Alpha? Should we
keep doing them?
No.
4) Add new milestones for Desktop freezes, polish, and "work all
done."
... how is 'work all done' something that's not already tracked?
Bill
6:29 p.m.
Bill Nottingham said the following on 11/02/2009 10:49 AM Pacific Time:
John Poelstra (poelstra(a)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. I'm not sure what period you
believe should be a month. Can you be more specific?
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 what I've created doesn't match this methodology, please point out
the differences. I intentionally added a week to the beta testing phase
to accommodate the creation of a "Test Compose" for the RC which is also
reflected in the methodology.
If the methodology should be changed we should update the methodology
and I can generate a new schedule. One change I would suggest off the
top is that the Alpha testing duration be reduced to 3 weeks and that
extra week be given to another part of the schedule.
> Questions:
> 1) Are we truly getting value out of the "Halloween/May Day" principle?
We are getting value of having a predictable release, IMO. If we want
to shift that slightly, we can, but I don't think moving to a cycle
where each slip slides all subsequent releases that same amount really
helps; we end up releasing at a semi-random time each year.
> 3) With the advent of the test days and ISOs for those events, are we
> getting any value out of the weekly snapshots during Alpha? Should we
> keep doing them?
No.
> 4) Add new milestones for Desktop freezes, polish, and "work all done."
... 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.
11:51 a.m.
John Poelstra (poelstra(a)redhat.com) said:
>John Poelstra (poelstra(a)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.
If you'd prefer I just use words like 'bad', let me know.
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.
>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.
>... 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,
Bill
12:29 p.m.
On Tue, Nov 03, 2009 at 12:51:43PM -0500, Bill Nottingham wrote:
John Poelstra (poelstra(a)redhat.com) said:
> 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.
IIRC that page consolidates previous written work from previously
existing pages, and the comments of rel-eng personnel. Is it really
new, or the same information presented in a different format that
makes it look new?
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
12:38 p.m.
Paul W. Frields (stickster(a)gmail.com) said:
> 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.
IIRC that page consolidates previous written work from previously
existing pages, and the comments of rel-eng personnel. Is it really
new, or the same information presented in a different format that
makes it look new?
The entire 'schedule methodology' section was added on September 18,
according to the wiki history.
Bill
1:02 p.m.
On Tue, Nov 03, 2009 at 01:38:15PM -0500, Bill Nottingham wrote:
Paul W. Frields (stickster(a)gmail.com) said:
> > 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.
>
> IIRC that page consolidates previous written work from previously
> existing pages, and the comments of rel-eng personnel. Is it really
> new, or the same information presented in a different format that
> makes it look new?
The entire 'schedule methodology' section was added on September 18,
according to the wiki history.
September 17 & 18, but if I read this right the meat came from these
pre-existing pages:
https://fedoraproject.org/wiki/Time_based_release_schedule
https://fedoraproject.org/wiki/Releases/Schedule
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
6:22 p.m.
Bill Nottingham said the following on 11/03/2009 09:51 AM Pacific Time:
John Poelstra (poelstra(a)redhat.com) said:
>> John Poelstra (poelstra(a)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
2:53 p.m.
Sorry about the delay - been drowning in F12 final hair-on-fire stuff.
John Poelstra (poelstra(a)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
8:31 p.m.
On 11/06/2009 12:53 PM, Bill Nottingham wrote:
Sorry about the delay - been drowning in F12 final hair-on-fire
stuff.
John Poelstra (poelstra(a)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.
The duration between public alpha and beta has been all over and I'm
unsure of its significance (if I understand you correctly below, you're
suggesting that measuring the time between milestones is meaningless):
(in days)
F8 - 21
F9 - 23
F10 - 35
F11 - 28
F12 - 56
F13 - 42 (original proposal)
I think a better way to break this down is to be more specific about the
tasks in between because saying "one month in between" is too vague. To
make it four weeks we'd have to set:
Alpha Public Release Available
2 weeks
--followed by--
Beta Freeze
2 weeks
--followed by--
Beta Public Release Available
I'd propose making the Alpha Public Release three weeks--the original
proposal was four.
For the past couple of releases there was been two weeks between the
freeze date and the public release date. We need two weeks to include a
"Test Compose"--granted I don't believe we were able to create any of
the Test Composes on time (something we should examine when creating the
F13 schedule).
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.)
I agree. I was following the methodology set forth by FESCo that the
submission deadline should be two weeks before Feature freeze. I'll
keep it in mind as other dates move around.
<cut>
> 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
Good distinction. You are right, we can't be both :)
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.
Meaning can be found in how long it actually takes us to complete
certain tasks and the overall durations of our schedules. Because when
we estimate these things wrong or don't meet the originally planned
schedule we slip (ship late). If we find that certain tasks are usually
complete on time or within an acceptable variance we know they they are
good durations to use in the next schedule.
Whether we target a specific GA date or say we are a '6 month cycle' we
still have to make decisions about how long each of the tasks can take
within the overall alloted time period. This results in trade-offs and
decisions about what parts of the schedule should remain the same for
each release and which parts can change without adversely affecting our
ability to meet the scheduled GA date.
We've generally found that we need a certain amount of time between
freeze and public release (2 weeks). We've also found that for a public
release to be worth creating it needs to be available for a period of
time before creating a new one. With these task durations less flexible
the schedule has to give somewhere. In the past several releases we've
been taking that off the development time (start to first freeze).
>> '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.
Interesting observation. I hadn't considered it this way. Are you
suggesting that we should handle blockers differently? Is this is a
good or bad thing to you?
> 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.
We reviewed the blocker list every Friday starting at least two weeks
before every freeze until release. What would you suggest as an
additional or alternate way to focus on blockers?
John
1:14 p.m.
John Poelstra (poelstra(a)redhat.com) said:
The duration between public alpha and beta has been all over and
I'm
unsure of its significance
The significance is that it's what sets the length of the alpha or
beta release.
(if I understand you correctly below,
you're suggesting that measuring the time between milestones is
meaningless):
No, that's not what I was saying. I was merely saying that measuring from
a variable 'start' date is meaningless if we're operating towards a fixed
end date each time.
(in days)
F8 - 21
F9 - 23
F10 - 35
F11 - 28
F12 - 56
F13 - 42 (original proposal)
Right - this is my point. In every prior release (except for F12), the
duration was 4 weeks, give or take 1 week. I think an initial proposal
of 6 weeks is excessive.
I think a better way to break this down is to be more specific about
the tasks in between because saying "one month in between" is too
vague. To make it four weeks we'd have to set:
Alpha Public Release Available
2 weeks
--followed by--
Beta Freeze
2 weeks
--followed by--
Beta Public Release Available
I'd propose making the Alpha Public Release three weeks--the
original proposal was four.
That's a reasonable point to make the adjustment - I'd still prefer
two weeks. What do other people think?
For the past couple of releases there was been two weeks between the
freeze date and the public release date. We need two weeks to
include a "Test Compose"--granted I don't believe we were able to
create any of the Test Composes on time (something we should examine
when creating the F13 schedule).
I don't understand this reasoning. The desired work flow, as I understand
it, is something like:
1) Freeze
2) Are there blockers?
-> No!
-> Party!
-> make Alpha/Beta/Release candidate compose
-> test, etc.
-> Yes!
-> Bummer.
-> make a test compose
-> test, fix, etc.
-> goto 2)
A test compose only exists when we know we still have blockers to solve.
Otherwise it's an alpha/beta/release candidate. Therefore, we shouldn't be
adjusting the freeze schedule to add time for a 'test compose'.
We can certainly have additional test composes outside of the freeze for QE
to look at, but I don't know that they're events that affect the schedule
duration as much as they are simply point events in the schedule.
>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.)
I agree. I was following the methodology set forth by FESCo that
the submission deadline should be two weeks before Feature freeze.
I'll keep it in mind as other dates move around.
Yep; any shortening of either of the alpha or beta cycles 'fixes' this
as a side effect.
>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
Good distinction. You are right, we can't be both :)
>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.
>
Meaning can be found in how long it actually takes us to complete
certain tasks and the overall durations of our schedules. Because
when we estimate these things wrong or don't meet the originally
planned schedule we slip (ship late). If we find that certain tasks
are usually complete on time or within an acceptable variance we
know they they are good durations to use in the next schedule.
Whether we target a specific GA date or say we are a '6 month cycle'
we still have to make decisions about how long each of the tasks can
take within the overall alloted time period. This results in
trade-offs and decisions about what parts of the schedule should
remain the same for each release and which parts can change without
adversely affecting our ability to meet the scheduled GA date.
We've generally found that we need a certain amount of time between
freeze and public release (2 weeks). We've also found that for a
public release to be worth creating it needs to be available for a
period of time before creating a new one. With these task durations
less flexible the schedule has to give somewhere. In the past
several releases we've been taking that off the development time
(start to first freeze).
Right, maybe I'm not being clear.
We have defined amounts of time that we need for each freeze, each
milestone's availability, etc. To do the schedule, we set an end
date (either releasing on a certain date, or releasing X time after
the prior release), and work each milestone backwards from there.
The 'start' -> milestone duration ends up not being an input to the
schedule, but a historical output; if we're adopting the philosophy
of releasing on May 1/Nov 1 each year, then we know that those
durations will be highly variable as a consequence of our release
philosophy.
(You could also make the argument that the 'start' time for release
N+1 isn't when N is released, but when N is branched. After all,
people have been able to build for F-13 for a while now.)
>>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.
Interesting observation. I hadn't considered it this way. Are you
suggesting that we should handle blockers differently? Is this is a
good or bad thing to you?
It's probably a good thing, considering an increased focus on quality.
>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.
We reviewed the blocker list every Friday starting at least two
weeks before every freeze until release. What would you suggest as
an additional or alternate way to focus on blockers?
Ideally, some way to drive through development getting blockers fixed
sooner rather than later; this means even at the alpha or beta timeframe
trying to weed out any final blockers. This does lead to interminable
meeting length, though. Maybe have major groups be required to send status
on all of their assigned blockers before each meeting, rather than having
to go through in a global meeting and determine status there?
Bill
3:54 p.m.
On Thu, 2009-11-12 at 14:14 -0500, Bill Nottingham wrote:
1) Freeze
2) Are there blockers?
-> No!
-> Party!
-> make Alpha/Beta/Release candidate compose
-> test, etc.
-> Yes!
-> Bummer.
-> make a test compose
-> test, fix, etc.
-> goto 2)
A test compose only exists when we know we still have blockers to solve.
Otherwise it's an alpha/beta/release candidate. Therefore, we shouldn't be
adjusting the freeze schedule to add time for a 'test compose'.
We can certainly have additional test composes outside of the freeze for QE
to look at, but I don't know that they're events that affect the schedule
duration as much as they are simply point events in the schedule.
With exception to the final release, releng provided "Test Composes" to
QE before the scheduled freeze point. This was to allow QE to run
through the matrix with isos and see what might still be broken, so that
we could fix it /before/ we froze. It was an attempt to remedy the
situation where we freeze, then discover all the bugs, and subsequently
slip whatever release we froze for. This is what I want to see codified
on the schedule, the test compose before the freeze. We need to focus
more testing and effort /before/ the freezes as our freeze times are
really short and we inevitably slip them.
Making freezes longer isn't really a good solution, as that directly
prevents further development and cheats the later dates, however we
really need to look at this schedule in the viewpoint of no frozen
rawhide.
I owe a more through reading/reply to this schedule thread, I'm just
answering one part of it here.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
7:41 a.m.
On Thu, 2009-11-12 at 13:54 -0800, Jesse Keating wrote:
On Thu, 2009-11-12 at 14:14 -0500, Bill Nottingham wrote:
>
> 1) Freeze
>
> 2) Are there blockers?
> -> No!
> -> Party!
> -> make Alpha/Beta/Release candidate compose
> -> test, etc.
> -> Yes!
> -> Bummer.
> -> make a test compose
> -> test, fix, etc.
> -> goto 2)
>
> A test compose only exists when we know we still have blockers to solve.
> Otherwise it's an alpha/beta/release candidate. Therefore, we shouldn't be
> adjusting the freeze schedule to add time for a 'test compose'.
>
> We can certainly have additional test composes outside of the freeze for QE
> to look at, but I don't know that they're events that affect the schedule
> duration as much as they are simply point events in the schedule.
With exception to the final release, releng provided "Test Composes" to
QE before the scheduled freeze point. This was to allow QE to run
through the matrix with isos and see what might still be broken, so that
we could fix it /before/ we froze. It was an attempt to remedy the
situation where we freeze, then discover all the bugs, and subsequently
slip whatever release we froze for. This is what I want to see codified
on the schedule, the test compose before the freeze. We need to focus
more testing and effort /before/ the freezes as our freeze times are
really short and we inevitably slip them.
Making freezes longer isn't really a good solution, as that directly
prevents further development and cheats the later dates, however we
really need to look at this schedule in the viewpoint of no frozen
rawhide.
I agree. I don't think I fully understand the unfrozen rawhide proposal
at first. And I'm not sure if it solves all of our problems, but I do
think it's worth exploring as it seems to address this "tension" around
blocking code progress, as well as standardizes on a method for
reporting test feedback (which helps QA).
What do you need in order to make progress towards
https://fedoraproject.org/wiki/No_Frozen_Rawhide_Proposal? Apologies if
this is moving and I just don't have visibility into its status.
Thanks,
James
4:45 p.m.
On 11/12/2009 11:14 AM, Bill Nottingham wrote:
John Poelstra (poelstra(a)redhat.com) said:
> For the past couple of releases there was been two weeks between the
> freeze date and the public release date. We need two weeks to
> include a "Test Compose"--granted I don't believe we were able to
> create any of the Test Composes on time (something we should examine
> when creating the F13 schedule).
I don't understand this reasoning. The desired work flow, as I understand
it, is something like:
1) Freeze
2) Are there blockers?
-> No!
-> Party!
-> make Alpha/Beta/Release candidate compose
-> test, etc.
-> Yes!
-> Bummer.
-> make a test compose
-> test, fix, etc.
-> goto 2)
A test compose only exists when we know we still have blockers to solve.
Otherwise it's an alpha/beta/release candidate. Therefore, we shouldn't be
adjusting the freeze schedule to add time for a 'test compose'.
We can certainly have additional test composes outside of the freeze for QE
to look at, but I don't know that they're events that affect the schedule
duration as much as they are simply point events in the schedule.
What you describe above is NOT what we scheduled or attempted for Fedora
12. We intentionally scheduled test composes before the freeze (as
Jesse is requesting for the Fedora 13 schedule)
http://poelstra.fedorapeople.org/schedules/f-12/f-12-releng-tasks.html
--see task #13 for Alpha
--see task #52 for Beta
I did not make this up on my own, we all talked this in the scheduling
meeting we held on FedoraTalk. :)
The difficulty we had in Fedora 12 was that we weren't able to get solid
Test Composes in most cases until right before the Freeze (Monday)...
not the prior Wednesday as scheduled. I'm calling this out NOT to fault
anyone, but to note what actually happened.
John
9 p.m.
John Poelstra (poelstra(a)redhat.com) said:
>>For the past couple of releases there was been two weeks
between the
>>freeze date and the public release date. We need two weeks to
>>include a "Test Compose"--granted I don't believe we were able to
>>create any of the Test Composes on time (something we should examine
>>when creating the F13 schedule).
>
>I don't understand this reasoning. The desired work flow, as I understand
>it, is something like:
...
What you describe above is NOT what we scheduled or attempted for
Fedora 12. We intentionally scheduled test composes before the
freeze (as Jesse is requesting for the Fedora 13 schedule)
http://poelstra.fedorapeople.org/schedules/f-12/f-12-releng-tasks.html
--see task #13 for Alpha
--see task #52 for Beta
I stand corrected. I'm still not sure that delivering pre-freeze
test composes should affect the length of the freezes.
Bill
7:38 a.m.
On Thu, 2009-11-12 at 22:00 -0500, Bill Nottingham wrote:
John Poelstra (poelstra(a)redhat.com) said:
> >>For the past couple of releases there was been two weeks between the
> >>freeze date and the public release date. We need two weeks to
> >>include a "Test Compose"--granted I don't believe we were able
to
> >>create any of the Test Composes on time (something we should examine
> >>when creating the F13 schedule).
> >
> >I don't understand this reasoning. The desired work flow, as I understand
> >it, is something like:
...
> What you describe above is NOT what we scheduled or attempted for
> Fedora 12. We intentionally scheduled test composes before the
> freeze (as Jesse is requesting for the Fedora 13 schedule)
> http://poelstra.fedorapeople.org/schedules/f-12/f-12-releng-tasks.html
> --see task #13 for Alpha
> --see task #52 for Beta
This isn't specific to the length between the milestones, moreso about
the QA checkpoints on the schedule.
I'd like to try another release while continuing with the QA testing
tasks for each milestone. I'm pretty confident this was a good thing
for F-12. For F-12, Alpha, Beta and RC [1] each had a QA checkpoint
for:
* pre-compose install verification (rawhide-based)
* test compose install verification (media testing)
* release candidate compose install verification (media testing)
[1] The RC didn't have a test compose officially scheduled, however we
did one anyway. I'd propose making it official for the F-13 RC.
Thanks,
James
12:31 p.m.
On 11/12/2009 07:00 PM, Bill Nottingham wrote:
John Poelstra (poelstra(a)redhat.com) said:
>>> For the past couple of releases there was been two weeks between the
>>> freeze date and the public release date. We need two weeks to
>>> include a "Test Compose"--granted I don't believe we were able
to
>>> create any of the Test Composes on time (something we should examine
>>> when creating the F13 schedule).
>>
>> I don't understand this reasoning. The desired work flow, as I understand
>> it, is something like:
...
> What you describe above is NOT what we scheduled or attempted for
> Fedora 12. We intentionally scheduled test composes before the
> freeze (as Jesse is requesting for the Fedora 13 schedule)
> http://poelstra.fedorapeople.org/schedules/f-12/f-12-releng-tasks.html
> --see task #13 for Alpha
> --see task #52 for Beta
I stand corrected. I'm still not sure that delivering pre-freeze
test composes should affect the length of the freezes.
Bill
I'm not sure either. History has shown, that we have a hard time doing
multiple things at the same time. I wasn't advocating extending the
freezes to accommodate the Test Composes, but instead the Public Testing
Duration of Alpha and Beta--time when releng and others aren't so 'hair
on fire' before preparing the next Public release :) This would (going
back to a prior discussion) increase the total time between the public
release of Alpha and Beta.
I'll try to come up with a new schedule scenario or two (factoring in
the things we've discussed here) to see if that can bring everyone
closer to agreement. I'll post them here by Monday, hopefully sooner.
John
5275
days inactive
5289
days old
rel-eng@lists.fedoraproject.org
16 comments
5 participants
participants (5)
-
Bill Nottingham -
James Laska -
Jesse Keating -
John Poelstra -
Paul W. Frields