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 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
