Next Release Planning

[Dave Neary]

Hi,

On 08/23/2012 10:59 AM, Yaniv Kaul wrote:
> On 08/23/2012 09:05 AM, Livnat Peer wrote:
>> +1, I suggest that instead of stabilizing what we have now, we'll send a
>> release date and a feature freeze (FF) date to the dev lists, and see if
>> there are any comments about the plan, maybe postponing FF by a week or
>> so can give us more features etc.
>> On the agreed FF date we'll create the 3.2 branch and ask all
>> stabilization patches to be cherry picked to the 3.2 branch.
>
> I may be a bit biased because I'm from QE, but I do suggest a different
> path - remain stable at all times.
> The huge delay in releasing 3.1 due to quality issues supports this.
> It means development may be a bit slower, but it'll pay off in release
> time and quality.

The major issue I see with the current way of doing things is that it 
makes it harder for developers to test their work. You have 2 active 
branches where work is getting done almost all the time, with the result 
that you need to keep 2 complete environments around to test both 
versions, it takes extra effort to be conscientious and back-port fixes 
from the devel branch to the pre-release branch, etc.

I suggested on IRC that features be developed entirely on branches until 
they're done and tested. That adds overhead to the developers too, and 
new features will still need some integration work when merged. But this 
would definitely get us closer to Yaniv's goal of an always-releasable 
branch.

When it comes down to it, I think it's useful to have everyone working 
in the same place for as long as possible - I much prefer having 
everyone working towards getting a release out the door, or everyone 
working on new features, rather than having people split their attention 
between both, and as a result neither gets done as well as they could be.

Cheers,
Dave.

-- 
Dave Neary
Community Action and Impact
Open Source and Standards, Red Hat
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13