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