Hi,
As you've been able to see, we still haven't produced an alpha4 RC,
slipping on a day to day basis because of a continuous stream of
blocking bugs. What's happening? When will that stop? What is the plan?
How can I help? This email intends to answer those questions.
**When will 0.7alpha4 stop?*
*The stated objective of alpha4 is to provide a stable and dogfoodable
version of Chandler. For this, we are building checkpoints on an almost
daily basis and have dogfooders using them so that we have some real
life assessment that the release is indeed stable and dogfoodable.
The current criteria to declare a checkpoint being stable and worthy of
becoming a Release Candidate is:
- has no pending bug marked 0.7alpha4 and blocking in Bugzilla
- has been used 2 consecutive days by dogfooders without them reporting
a blocking issue
So far, we haven't reached those criteria (i.e. we found a blocking bug
almost every day). Hence we haven't declared an RC despite the fact we
have branched the code on October 26th. On top of that, we also want to
dogfood against osaf.us so we are doing some extra QA steps to make that
as smooth as possible.
So, to answer the question, 0.7alpha4 will stop when we'll have a build
that reached stability (see above) and qualify against osaf.us (see
below). This is still several days away.
**What is a blocking bug?*
*The Bug Council get together every day and review the new untargetted
bugs. We mark as blocking bugs that prevent dogfooders to use the
application. Those are:
- reproducible crashers
- situation of data loss - loss of major functionality
All other bugs are not considered blockers.
**What about those 0.7alpha4 non-blocking bugs?*
*Those are bugs that we'd like to take a fix for opportunistically (as
long as the RC is not declared and we build checkpoints...) *IF* the fix
is very safe. We will punt to alpha5 if the fix is risky in any way
(even so slightly). We try to limit the number of those bugs as well
since they are a distraction on the dev team.
**Are we testing against Cosmo 0.5?*
*We want to encourage dogfooders to use the new osaf.us service which
has been upgraded to Cosmo 0.5 so, yes, we need to be testing against
Cosmo 0.5. We still need to run a full qualification test between
Chandler 0.7alpha4 and Cosmo 0.5 so how does that work with 0.7alpha4 RC
schedule? Here's a scenario of what will happen starting at (t0 = now):
1- get to a stable alpha4 checkpoint (+x days, as soon as we meet the
criteria listed above)
2- run a full qualif test between that Chandler 0.7alpha4 checkpoint and
Cosmo 0.5 on osaf.us (+1 day)
3- if any interop bugs are found, fix those on the 0.7alpha4 branch and
create an 0.7alpha4.1 version (+y days)
4- build an RC
5- QA to run the usual qualif tests on the official RC (+1 day)
6- make the rest of the World know about 0.7alpha4 release and Cosmo 0.5
and encourage them to upgrade
"x" is likely to be a couple of days (may be tomorrow).
"y" will hopefully be "0" since we've been doing dogfood testing and
running TBoxes against osaf.us since a while already.
All in all though, we are at least 4 days from declaring RC.
**Is testing on a public server like osaf.us really kosher?*
*No and this is only a temporary measure so that we get some level of
testing on it before it becomes really open to the public and to make
sure that, indeed, dogfooders and early adopters can use it. Eventually,
we will use a clean stable Cosmo server (cosmo-test) to run TBoxes. The
details of this have been discussed in a recent QA meeting which notes
can be found here:
http://wiki.osafoundation.org/bin/view/Journal/BuildReleaseMeeting20061030
**What can I do to help?*
*If you're a dev, keep a eye on those alpha4 bugs that get assigned to
you and keep them moving.
Everybody should use 0.7alpha4 checkpoint builds *exclusively*!!!!
Please, do *not* use alpha4 and alpha5 concurrently on the same shares
as it may create interop issues that have nothing to do with declaring
an RC on alpha4. Untangling those interactions can be tricky and we are
wasting quite a bit of cycles right now figuring out which version
created what issue on which share. The best is simply to avoid those
situations entirely.
If you need to test alpha5, do it on its own repo and, if you need to
test with Cosmo, do test on special shares separated from your dogfood
shares (even better, do it on another account).
Cheers,
- Philippe
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
