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