[Chandler-dev] Chandler Desktop Releases

[Philippe Bossut]

Hi,

We've been discussing during the last Desktop meeting about the release 
process and the idea to move from a Feature Driven Release to a Schedule 
Driven Release (see the meeting notes: 
http://chandlerproject.org/Journal/AppsMeeting20070918#Move%20to%20scheduled%20releases). 
The main motivation is to get to a situation where we release Chandler 
more frequently so we don't delay getting bug fixes and new features in 
the hands of users for months. This point at least is one with a general 
consensus (echoed by Andi's "no more 9 months releases" quip and others 
folks similar comments here on that list).

There were some points made during the meeting so no clear consensus 
achieved. We agreed to bring the issue to the list (which I'm doing 
right now).

Proposal and points of contention:
- Release once a month: some proposed 6 weeks (4 weeks dev time, 2 weeks 
debug stabilization) but the idea is that we work under an evergreen 
trunk policy so we don't destabilize trunk, also a monthly release makes 
it easier to punt something to the next release (users won't have to 
wait too long) than a 6 weeks cycle.
- Choice of what makes it in releases: we need a process to decide what 
makes it into a release, the risk is to take too much and slip so making 
the process moot. The point of rapid cycles though is that punting is 
not a huge penalty to users so getting a feature punted is not a big 
deal, we can consider the release cycle like a pick up system, the 
release being whatever made it to the pick up time. We need a system 
though so that devs know what to work on first (see below for a proposal).

Process (draft, lots of details to be worked out but that's the basic):
- All bugs fair game for 0.7.x releases marked targetted "0.7.future"
- Bug Council and PPD to set the priority and put a set of those bugs in 
current targetted release (e.g. "0.7.1")
- Devs to work on those (in branches if necessary): Commit small fixes 
(after code review) on the trunk, keep big fixes and feature development 
(e.g. month view, big refactoring projects) on dev branches (this is 
basically Grant's s3 proposal for SVN). Heikki pointed that this 
certainly means we need a policy for accepting big dev branch merges 
only at the beginning of cycles (in the first 2 weeks for instance).
- 1 week before branch time, check where unfinished stuff are and punt 
the ones that are too risky to take that late (they'll be picked up next 
time)
- on T0 branch and start QA acceptance procedure
- on (T0 + 1 week) release (possibility of small bug fixes on the branch 
if blockers found but we expect them to be few considering the dev process)

Notes:
- QA needs a week to qualify Chandler Desktop on the 3 platforms (run 
the acceptance tests) so a super frequent release cycle would be impractical
- The first iteration will be longer than the others due to the 1 week 
QA process but note that the dev cycle of the next version start at T0 
(as soon as we branch)
- Cosmo is currently using a similar process (so it's not like we're 
jumping in total unknown...) and it worked apparently pretty well for 
them. We have some extra process challenges though for Desktop but I'd 
like to see a consensus on the general idea before splitting hair on the 
minutiae of the process.

Comments very welcome.

Cheers,
- Philippe