[Cosmo-dev] Cosmo 0.7.1 release plan

[Ted Leung]

Hi folks,

Things are a little scrambled because of the long weekend, and  
because this is our first time doing a quick turn release.   Here's  
our current rough plan for 0.7.1.   Please keep in mind that this is  
our first time doing things this way, and that we are likely to have  
hiccups and make improvements in subsequent weeks.

- Katie will move the bugs from 0.7.future to 0.7.1 and set the  
severity flags to reflect PPD priority for those bugs.   Please work  
on bugs in severity order.  If all bugs have the same severity, then  
you are free to work on whichever bugs you deem most important.   I  
hope to actually use the priority fields on bugs to help disambiguate  
these cases, but for now, the highest severity bugs should get  
priority.   In the meantime please swag any unswagged 0.7.future bugs.

-  Our goal is to have a release on a fixed day every week.   Due to  
the need to also update the hub, it's probably best that this day not  
be Monday or Friday.  One proposal for this day was Tuesdays, which  
would mean that 0.7.1 would be scheduled for next Tuesday,  Sep 11.

- QA needs three days before the release date to validate whatever  
changes get made.   If we work backwards from next Tuesday, that  
means that QA needs to begin this Thursday, which leaves us basically  
tomorrow to make whatever fixes are going to get into 0.7.1.   Once  
QA begins, developers can start working on bugs for 0.7.2, which will  
be whatever bugs don't get done by Thursday morning.   I know that  
this makes for a small 0.7.1, but I think that it is important to  
establish a regular pattern of releasing and to target that to the  
most desirable day (in general) for us to make these releases.  To be  
clear: if a bug is not complete on Thursday morning, then it is  
getting punted to 0.7.2.  We are not holding releases for bugs that  
are not done.   Quick turn releases are like a pipelined CPU.  It  
takes a little while for the pipeline to fill up and achieve the  
desired throughput.

- We've only seen one proposal for how to manage branchng, so we're  
going to do that one, which is to base the 0.7.x branches off of  
0.7.   We will merge the changes from 0.7.1 into the trunk when 0.7.1  
releases, but we will also merge them into 0.7.2 as soon as QA begins  
so that 0.7.2 development can proceed.   It is going to be important  
to keep the .7.x branches and the trunk in buildable/releasable states.

- We still haven't worked out the complete process for allowing  
anyone to nominate bugs for an 0.7.x release.   Given the short  
length of 0.7.1, this is probably moot, but I want to have this  
worked out by the time we get started on 0.7.2

I'd like to reemphasize that we are going to be learning as we go on  
this, so I'd encourage people to speak up with ideas for how to  
improve the process.

Ted