[Chandler-dev] Chandler Desktop Releases
aparna at osafoundation.org
Tue Sep 25 09:59:52 PDT 2007
Other than the lack of large set of automated sets that is sort of
critical for the sucess of shorter releases, that Dan already pointed
out, everything else looks good.
One other thing I would like to bring up is our cycle of weekly IRC
collaborative QA sessions and how important it will be going forward
to have everyone participate in it. THis cannot be emphasized more
especially in the light of newly planned shorter Desktop releases.
On Sep 21, 2007, at 5:11 PM, Philippe Bossut wrote:
> 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://
> 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
> - 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)
> - 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.
> - Philippe
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Open Source Applications Foundation "chandler-dev" mailing list
More information about the chandler-dev