[cosmo-dev] Release terminology

[Aparna Kadakia]

On Dec 10, 2007, at 8:11 AM, Randy Letness wrote:

> Mikeal Rogers wrote:
>>
>> 2. "Triple Zero" -- 0 open untargetted bugs, 0 open bugs in the  
>> release, 0 automated test failures
>>   - If the release branch hasn't happened yet, it should happen now.
>>   - If QA wasn't automating features tests before this, they are now
>>   - At this point bear should do a release build and mark it RC1 so  
>> that outside contributors may start testing the build at home. This  
>> will also flush out any release build related issues.
>>   - QA provides an estimate to when they will be done adding new  
>> automated tests to this release. This timeline will obviously  
>> reflect how much time QA was spending on these features beforehand.
>
> Whats the difference between "Triple Zero" and RC?


"Triple Zero" is basically a point during the development process that  
triggers a few things for QA as well as Build/Release like doing the  
release branch, adding automated tests for the new features in the  
release, etc.  Bear *may* also spin a  release candidate1 that is  
mostly for the outside contributors who are testing the builds at  
home. The term release candidate typically implies that new feature  
testing is done and we are closer to releasing which might not be true  
at all. In reality QA might have just begun new feature testing on  
this release causing the flurry of new bugs and churning of new  
release candidates. This is exactly the reason we want to decouple the  
two. We want to identify the hand off from development to QA and not  
tie it to RC.


> I think a problem we were running into was that an RC was cut before  
> any real feature testing was done.  New bugs were found, and we  
> would wait a while before cutting another RC (a manual process) and  
> verify those bugs as fixed.  This could be a lag time of a few days  
> and in some cases would result in the bug being punted because to  
> prevent another RC.

Exactly!

> What about testing from checkpoints, that are built automatically,  
> if possible.  That way when a bug is fixed, it can be verified in  
> the next checkpoint. When all bugs are fixed and verified, then an  
> RC is cut and final certification testing is done.
>

We don't want to complicate the testing process by adding another  
level of testing checkpoints. QA relies on constantly building from  
sources so verifying bugs will only be faster than waiting for the  
next RC.  When QA is done with what we call "certification" (refer to  
Mikeal's original email) , a final RC will be cut, sanity tested by QA  
and ready for release.




> -Randy
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev