[Chandler-dev] 0.7.1 BRANCHING TONIGHT!
aparna at osafoundation.org
Wed Oct 3 13:54:35 PDT 2007
I'd like to call out the QA impact and process to be followed
thereby, in light of the shorter release cycles. This specifically
applies to 0.7.x releases and not big feature releases like 0.8 or 1.0.
1. Till the record/scripting framework gets stable and we are able to
add substantial automated tests to the new framework, most of the
testing will continue to be manual. We will rely heavily on
developers writing more unit tests for bug fixes and features being
2. Be sure to run unit tests and functional tests to make sure your
checkins don't cause any regressions. Tinderboxes staying green is
crucial to this process.
3. Code review and bug numbers associated with checkins are still in
4. Given the shorter bandwidth of the QA team, we will not be able to
do a full-blown testing cycle for each release, meaning we won't be
going thru' all the test cases from the test specs on every
platform. The plan is the following:
a) Run acceptance tests on all platforms
b) verify bugs fixed in the release
c) if there are significant bug fixes related to a single
component in the application, then we will likely run thru all the
test cases for that component. For e.g. if we rework the triage table
view for a specific 0.7.x release, then we will run thru all the
testcases from the Dashboard spec for that release.
c) once a release candiate is handed to QA, we will do daily IRC
bug fests (or on alternate days as may be the need).
d) continue using the application internally for all of our
scheduling and task management needs.
Lastly, to reiterate what Philippe said, if you are unsure about the
riskiness of your fix, please err on the side of caution. QA won't
likely be going thru all test scenarios in each release.
If you have any other ideas on how we could enhance our testing scope
or make it more efficient, let me know.
On Oct 3, 2007, at 12:21 PM, Philippe Bossut wrote:
> Hi guys,
> Sorry for "shouting" in the title but I need your attention: we had
> a Bug Council this morning on IRC and talked about the "scheduled
> release" some more. Question: when do we start? Answer: Now!
> The other alternative was in some weeks from now but we voted
> against it. There was several reasons for it among them:
> - let's get in new good habits now
> - let's work out the kinks of the process while we're under no
> "urgent" feeling
> - it's easier for QA to qualify something that has a couple of
> weeks of bug fixes than 8 weeks (if we were to wait till the end of
> - let's have a clean 0.7.1 before landing some of the upcoming dev
> branches (we have 3 in the work right now: script recording (John),
> month view (Jeffrey) and jcc (Andi)).
> Here is what will happen:
> - tonight, 8PM PDT: bear will branch trunk to create an 0.7.1
> branch. So, you have till tonight to land your current fixes which
> should concern a dozen or so bugs with patches attached in
> Bugzilla. Please, do not commit some big/risky stuff right now
> obviously. If you're in doubt about the riskiness of your fix, err
> on the side of caution and wait till tomorrow. Your fix will make
> it in 0.7.2
> - tonight or tomorrow early: I'll retarget all non fixed 0.7.1 bugs
> to 0.7.future and migrate a fair amount of them to 0.7.2. I still
> need to send an email about that process but, essentially the idea
> is to lower the current bug count so that we all know what we're
> working on while parking "soon" bugs in 0.7.future rather than the
> catch all "future". Cosmo used a similar strategy when their 0.7.1
> list was too big to manage in 1 cyle (which is our case right now)
> - tomorrow: bear will build 0.7.1 and QA will start acceptance
> tests. The trunk will be reopen for 0.7.2 fixes
> - October 10th is the official release date for 0.7.1 (the time we
> need to qualify the build and, may be, fix some blockers)
> - November 7th will the release date for 0.7.2 so pick up date
> (date of last commit) for 0.7.2 will be October 31st
> OK, I'm working on this "process email" summarizing what we
> discussed last week (see notes http://chandlerproject.org/Journal/
> DesktopBuildReleaseProcessMeeting20070926) so the process shouldn't
> surprise anyone, just the timing.
> Concerns? Please speak up.
> - Philippe
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Open Source Applications Foundation "chandler-dev" mailing list
More information about the chandler-dev