[Cosmo-dev] Cosmo planning status

[Ted Leung]

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

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