[Dev] Phases and 0.7 milestone schedule

[Katie Capps Parlante]

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

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.

Cheers,
Katie