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
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
