[Cosmo-dev] Cosmo planning status

[Mikeal Rogers]

Everything sounds good below but I would like to bring something up.

The Chandler terminology for the previous releases has been to have  
"alpha" releases of 0.7. These "alphas" have been milestone releases,  
each having one or more RC builds and bugs fixed on those RCs, new  
RCs built and eventually released for distribution as a milestone  
release.

So, on the Chandler end alphas have been milestone releases and RCs  
are candidates for that milestone release.

I think much of the confusion has been around us using the  
terminology differently on the Cosmo end. We should probably sit down  
and align our terminology or choose a different set of terms for  
cosmo if we intend to do the release management and milestones  
differently on cosmo -- which I imagine we will.

-Mikeal

On Sep 26, 2006, at 11:49 AM, Ted Leung wrote:

> See comments in line
>
> On Sep 26, 2006, at 10:37 AM, Mikeal Rogers wrote:
>
>>> Question: Do was need a release candidate of 0.5 alpha1 to be put  
>>> on osaf.us once it is certified by QA?
>>> If yes, how long will that take? (Jared: perhaps you can answer  
>>> this and include your plan on moving dogfood users from cosmo  
>>> demo to osaf.us)
>>>
>>
>> For me to certify the release for production I additionally  
>> require the code to be branched, any bugs that are found to be  
>> fixed on the branch, and additional rc's built and tested until we  
>> have a build that passes all testing.
>>
>
> Understood.  The question is whether the purpose of "alpha"  
> releases is to be put into production.   I would say that the  
> answer is no.
>
>>> Here is the status I have for 0.5 so far for :
>>> + The drop to QA should be approximately 2 weeks after 0.5 alpha1  
>>> drop to QA? (Ted: please correct me if I'm wrong here? There is  
>>> branch for the dev. to keep working on the cosmo ui features?)
>>
>> If we branch the code, test, bug fix, and re-test the rc's so that  
>> we can certify the build for production then there will be a hit  
>> to development and I doubt the 2 week assumption on development  
>> time will be unaffected.
>>
>
> The "drop to QA" that Prisiclla is referring to is the first 0.5  
> release candidate.
>
>>>
>>> There seems to be a lot of confusion and discussion around this  
>>> current release. Please clarify as you see fit.
>>
>> Here was the plan as I understood it.
>>
>> QA would get a drop of cosmo, we were calling this RC but a better  
>> word for how I understood it would be SNAPSHOT. This build would  
>> go through a full QA cycle and bugs would be logged against it. My  
>> understanding was that no bugs would be fixed against a 0.5alpha1  
>> branch and would instead only be fixed in the trunk and another  
>> build would not be produced until 0.5 rc1.
>>
>> I can certify that QA ran all of our tests and logged all the  
>> necessary bugs against a drop of cosmo, but I can't certify  
>> anything for distrobution, much less production use, unless we are  
>> branching the code for the alpha and fixing all the necessary  
>> bugs, building additional rc's if necessary and running regression  
>> and acceptance testing on each rc until everything passes.
>
> The two paragraphs above were how I understood the plan as well.
>
>>
>> I hope this illustrates the difference in time and resources that  
>> would be required between a full test cycle on a cosmo build and a  
>> full certification of cosmo for production use.
>
> Understood.
>
> There are several parties with differing needs here:
>
> - PPD:
> Would like to have release that contain sensible units of  
> functionality.  Also, I am assuming that frequent releases are  
> better because it allows us to obtain end-user feedback sooner  
> rather than later.  Also PPD would like to have visibility/ 
> predictability vs the release schedule.
>
> - Development:
> Would like to get testing of intermediate units of work, so that we  
> have some visibility of how many bugs we will be looking at during  
> the endgame, as well as intermediate units of functionality for  
> PPD.   Development would like to issue one or more branches/builds  
> which can be tested by QA to obtain that visibility.    Development  
> does not plan to address bug fixes in  branches/builds -- they are  
> solely for the purpose of getting information about our situation  
> during the course of a release.   We can call these branches/builds  
> whatever we like -- I have been using the term alpha to refer to  
> them, but I don't really care what we call them.
> When all the work for a release has been done (including previously  
> logged bugs), then development will hand a branch off to QA.   This  
> branch would be the first release candidate (rc1).
>
> - QA:
> Needs a branch which is ready to be certified in preparation for  
> handing off to Hosted Service.   Initially this is rc1.   QA will  
> test rc1 and log bugs, and development will fix all logged bugs to  
> produce a new rc build.  This process will continue until QA  
> determines that all tests have passed.  Call that final branch rcH
>
> - Hosted Service:
> Needs a branch which has undergone QA testing.  This branch is  
> rcH.  rcH will be installed on some machine where it can verified  
> as suitable for full production.   If rcH has bugs that prevent use  
> in production, than additional release candidate builds will be  
> issued until we have a branch suitable for production.  These  
> release candidates will need to go through QA as well.
>
>
> The implication here is that we only try to certify the final  
> release build (via the rc's) for production, regardless of whether  
> they are actually put into production.   Assuming that we can  
> actually attain a release cycle time of 1 month, that would mean  
> that the Hosted Service would be able to upgrade production  
> machines at roughly that frequency, should that be desirable.
>
> So to translate this to our current situation.   Cosmo 0.5alpha1 is  
> a visibility build/branch.   We would like QA to run tests and log  
> bugs, but we do not plan to respin alpha1 to address those bugs.    
> As soon as Bobby and Matthew finish with recurrence/manage events,  
> we will start on Cosmo 0.5rc1, and turn on the full release machinery.
>
> Priscilla, Mikeal, and Jared, please speak up if the scenario above  
> does not address your needs.
>
> Ted
>
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/cosmo-dev/attachments/20060926/d1deb060/attachment.html