james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vincenzo Gianferrari Pini <vincenzo.gianferrarip...@praxis.it>
Subject Re: AW: [VOTE] Using of 2.3 branch
Date Thu, 21 Dec 2006 18:21:56 GMT

Stefano Bagnara wrote:
> 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).
Mine was just an example of the need that many of us have of building 
quickly minor enhancements that can be useful to others, and avoiding to 
mantain custom builds. In parallel with the real major work to be done 
in trunk anyway.
> 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.
Ok, I change my vote (always open to change my mind): Let's do "svn cp 
v2.3 next-minor" or "svn cp v2.3 2.4" as soon as possible.
> 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.
Here is the point: I think we should not wait too much before branching. 
I would try to freeze quickly 2.3.1 and then branch next-minor/2.4.
>> 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
> http://www.apache.org/foundation/glossary.html
> http://www.apache.org/foundation/voting.html
> 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.
> Stefano

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

View raw message