On December 15, 2010 07:33:13 am Rogier Wolff wrote:
> Do you mean that the default branch and 2010.4 branch diverged in the
> past?

Yes.  Natural evolution.  The release branch stays put and the default branch 
is added new features new strings are added to default with most new features.

 
> But for us, wouldn't it be easier next time to just have default
> converge to 2010.4, and continue development/merging of not-now stuff
> after the release?

Done properly, none of the two alternatives is easier or harder.  The 
advantage of the current process, introduced after 0.8.0, is that the release 
process is not a bottleneck to development.

What is new in the current release cycle is that it is not only default that 
added the strings (natural), but also 2010.4 added some strings of its own 
that will not be part of the main codebase.  It was my initiative (the 
dedication of the release) and I'll make it work.

There is no way that we'll go back to the "stop-and-go" model that you 
describe as "easier for us".  This project suffered under "stop-and-go" for a 
long time (until 0.8.0), resulting in:
* less than one release per year
* painful and long release process
* huge backlog of "not-now-stuff" lingering and aging

With the current process we made three releases in 2009 and two so far in 
2010.  Hugin may not be a huge project, but it is to big for the stop-and-go 
process that you qualify as "easier for us".


> Or am I saying something stupid?

I would not go as far as qualifying your statement as "stupid".  I just think 
you don't get the scale right (5 devs working on release and 10 working on new 
features).

I estimate that we have about 5 people working on release indeed; and just in 
the context of the Google Summer of Code there are another 5 students + 5 
mentors working on new features every year for the past four years.  I also 
estimate that about 50% of the new features are Google Summer of Code results; 
while the other 50% are the result of tireless volunteers.

Yuv

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to