Hi,
Today is the scheduled date for Chandler Desktop Code Complete.
By Code Complete we mean that all the *code* is in (i.e. this does not
apply to documentation issues) and that it passed some level of testing
already (i.e it's not partially there nor it is broken beyond being
usable). So that milestone can be declared passed only if no feature is
under development and if all features have been stamped by QA as "OK
(barring few logged bugs)".
According to that definition, we've been there since a while but the
amount of bugs left was too high to make things qualify as "OK (barring
few bugs)".
The Bug Council will meet tomorrow and state if Chandler Desktop meet
that bar and the milestone can be declared as reached. If we think that
some bugs/issues that prevent that to happen, those will be logged (if
not already) and promoted to P1/blocking (as in blocking the milestone).
After Code Complete, the name of the game is "stabilization" so we want
to reduce the risk of destabilization as much as possible. That means as
many eyes on each change as possible. The only bugs we'll be fixing will
be "must fix bugs" as decided by the Bug Council. The usual end game
restrictions will apply:
- only commit with a bug associated with them will be allowed
(exception: fix to tests)
- code review will be required for all checkins. We'll use the Bugzilla
review request system as we had in the past.
- all bugs need to be reviewed by the Bug Council before being triaged
into the release
- evergreen tree: commit that break the build or test will be promptly
rolled back
The biggest change for devs then are:
- you may have to log a bug and get it triaged so that this issue you
want to fix makes it into the release
- you'll need to create patches, attach them to Bugzilla and get a peer
review before committing
- don't forget to add the bug number and the reviewer in your svn commit
(use "bug xxxx, r=johndoe" at the beginning of your commit message) or
your commit will be rolled back
To make this process smooth, the Bug Council will increase its schedule
and meet 3 times a week (Monday, Tuesday, Thursday) or any ad-hoc time
in case of emergency (e.g. bug newly found that needs a quick turn
around). Devs can ping any member of the Bug Council any time to get a
bug on the fast triage track.
After Code Complete, we are planning to hit ZBR (Zero Bug Release)
within 2 weeks. After ZBR, we will create an 0.7 branch and build daily
checkpoints (aka Release Candidates) and only allow "recall class bugs"
to be fixed on that branch till we reach complete stability, measured as
a period of 3 days without such bugs being found and all QA tests and
reviews passed.
We're almost there! In the meantime, let's squash those remaining bugs!
Cheers,
- Philippe
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
