james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: AW: [VOTE] Using of 2.3 branch
Date Thu, 21 Dec 2006 17:53:01 GMT
Vincenzo Gianferrari Pini wrote:
>> You should do this in trunk. Trunk is where development is done. After 
>> you have done this in trunk we can discuss wether to backport it to 
>> some branch.
> And I will do it that way. But then I need to immediately backport to 
> 2.3 (or 2.4), because I have to deliver it to a Client with my extension 
> (I'm using this as an example, but is real :-)  ).

Well, I understand this, but we cannot change the whole James roadmap 
because of your needs, Noel's needs, my needs or anyone else here. If we 
do this for my needs then we should break any compatibility today and 
add DSN support (that I shipped 1 year ago to a client as a custom 
change and it would be really cool if it was part of james and I 
wouldn't need to merge the whole thing at every new release).

I know that 2.2.0 had a lot of bugs but we never released a point 
release to fix bugs. We waited 2 years for 2.3.0 to be published: I know 
that many James developer was using custom builds because of this.

Now I would avoid a "war" to decide wether to publish 2 or 3 releases in 
the next 6 months, otherwise we'll end up with no release at all ;-)

I just asked forever to not use the "v2.3" folder of our repository for 
new features, and it seems I was not the only one asking for this. I 
believe, as I suggested in past, that an "svn cp v2.3 next-minor" would 
have solved a lot of problems.

What I expect from someone that actively want to work on the 
point/bugfix release or next-minor is to apply every common issue to the 
v2.3 branch (license headers, agreed critical bugfix backports) *then* 
branch next-minor.

> For me it's all the same: the only difference is that if we have 2.3, 
> 2.4 and trunk we have to backport twice any fix. But let's then create a 
> 2.4 branch.

And when we'll have branched next-major we'll have to do this 3 times :-(

Btw I think that it is better to have 3 developers that actively can 
work on each of the 3 branch than having 3 developers that do nothing 
because they discuss the whole day about what to do in the common 
branch, why and how...

>> This is why backporting can be done with a vote after a proposal 
>> including the list of intended backports is done. As I said I prefer 
>> RTC for the v2.3 branch, but I'm not against using CTR: I thought that 
>> people that loose time working on that code would be happy to know 
>> ASAP if I will vote -1 to a release including what they just 
>> backported. Of course a single -1 will not block the release, but a 
>> majority of -1 will do, so it is better to understand each others and 
>> define the roadmap.
> What are RTC and CTR :-)  ?

Review-Then-Commit and Commit-Then-Review

ASF seems to be more restrictive than us on the practice. Lazy consensus 
is allowed in CTR with this workflow:
"The patch below fixes bug #8271847; if no-one objects within three 
days, I'll assume lazy consensus and commit it."

So, for ASF, even CTR with Lazy Consensus would need a message to let 
others to know what is going to happen.

I believe that we don't need a so restrictive workflow, but I think that 
at least when there is no clear consensus it is better to use a vote to 
have it clear and avoid the work of reverting changes.

You know I've always said that I favor CTR because things can be 
backported if needed, but this should be done if the veto is not 
resolved. This is why I think we should either resolve the current veto 
on v2.3 or revert the commit if we want to "unlock" that branch, 
otherwise it will become a mess. This is something that should not 
happen at all in a maintenance branch.


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message