[Chandler-dev] The Road to alpha4 Release Candidate

Philippe Bossut pbossut at osafoundation.org
Wed Nov 8 14:44:43 PST 2006


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


More information about the chandler-dev mailing list