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
checked in.
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
effect.
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.
Thanks
Aparna
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
October)
- 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.
Cheers,
- Philippe
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
