[Cosmo-dev] Cosmo 0.7.1 release plan

Ted Leung twl at osafoundation.org
Tue Sep 4 17:14:42 PDT 2007


No, not all the bugs on Katie's lies will get fixed in 0.7.1.     
0.7.1 is a fixed time duration release.    We pick the day we decide  
we want to release (Tuesday was proposed).    We figure out how much  
time we need for QA. and go back that many days (3 days).   Whatever  
day we land on is the day when development stops.   Bugs that are not  
done on that day will get into the following 0.7.x release.  We are  
not waiting for late bugs.

Ted

On Sep 4, 2007, at 5:08 PM, Aparna Kadakia wrote:

> QA team's current estimate of 3 days is considering all of the  
> current bugs on Katie's list get fixed in 0.7.1. If this list is  
> indeed shorter, we may be able to turn things around faster.  In  
> general if we plan shorter releases (one per week as mentioned  
> below) then the 3 day QA time seems reasonable. Some of that can  
> coincide with the development time and help cut it down a little.
>
> +1 to the overall process otherwise.
>
> On Sep 4, 2007, at 4:55 PM, Ted Leung wrote:
>
>> 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
>> _______________________________________________
>> cosmo-dev mailing list
>> cosmo-dev at lists.osafoundation.org
>> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev
>
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev



More information about the cosmo-dev mailing list