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