[Dev] Phases and 0.7 milestone schedule
Katie Capps Parlante
capps at osafoundation.org
Wed Feb 15 20:30:12 PST 2006
Alec Flett wrote:
> 1) We, as a team, anticipate an upcoming milestone/alpha release within
> 2-3 weeks of the actual release. This means we delay risky fixes until
> the beginning of the next milestone. I would hope that this "buckle
> down" period is identified as a part of the milestone schedule from the
Agreed, I was assuming a period like this. Agreed that it should be part
of the schedule from the start. I think Heikki mentioned two weeks --
does that sound reasonable to everyone?
> 2) In the last week (?) of the release, the product release team
> identifies the critical bugs necessary for the milestone and stops
> accepting most "easy" fixes.
I'm assuming "product release team" == "bug council". I think bug
council needs to be meeting regularly throughout the release,
continuously trying to keep bugs targeted to the right milestone. I
agree that the bug council needs to be strict about what fixes are let
in during the last week. This will be the case whether or not we go with
heavier use of branching and more atomic commits -- we still have to
make decisions about what goes in the milestone.
> 3) The development team doesn't try to accomplish too much in one
> milestone. For instance, if we finish the bulk of the dashboard phase 1
> work in the first 3 weeks of milestone 1, then we stop working on
> dashboard in milestone 1 and focus on bringing other key tenets up to
> milestone 1 level - or we make more robust tests, or we do architectural
> planning for milestone 2, etc etc..
I assume the concern here is that you don't want dashboard phase 2 work
to be 1/2 done at the milestone, thereby risking the stability of the
milestone. I agree that we need to be careful about that -- branching
and working on other tasks (tests, planning, other tenet work, bug
fixes) are indeed all options to consider. I think it is also possible
that some phase 2 work could make it into the milestone build if it
happens in stable chunks. For example, perhaps Grant ends up
implementing CALDAV free-busy support in phase 1, even though it is not
absolutely needed until phase 2. (Not the current plan, just picking an
example). I think the important factor is that whatever we check in for
the milestone, it implies a commitment that it will be stable/finished
enough to not threaten the milestone.
More information about the Dev