Noel, I understand your position, but I'd like to hear opinions of all
committers before starting the branch, and I would like that a +1 to
branch would means also that there will be effort to mantain that branch.
So, what you propose is not a branch for the alpha release, but a branch
for the whole 2.3.0 release. This would mean the branch is feature freezed.
As I said before I don't think it's worth to feature freeze here. I
consider the current trunk nothing more than a milestone.
Btw I started this thread because I know you may have different
opinions, so let's talk about this.
Your "we don't really have a choice" is your opinion or is something
related to some apache/james rule I don't know?
When you say "and merge in the recent *FIXES*." the commit I listed are
the list of fixes.
About the prior proposal/discussion I want to make clear that every
commit I do is subject to review. IIRC we agreed to work in a
Commit-then-Review style because I was almost the only one working on
sources and because a commit worth more than thousands words.
When I commit new features and refactorings I always add comments in svn
logs and to JIRA issues: I would really like to discuss any change, and
I actually ask for comments every time.
Personally I don't think that the "discuss" style I saw in this list in
the last 2 years worked too much. We have plenty of uncomplete
discussion threads, we have many wiki pages or website pages not updated
or reporting outdated proposals.
Often it takes much less to do things than to discuss them, so I simply
choose this way (en example is the JamesSpoolManager refactoring: I
would have lost hours trying to explain the idea, it took much less and
it is more clear to commit the change).
I would not mind to revert refactorings or new features commit: simply
start a discussion and I'm sure we can find a different solution or
agree to keep or revert the change.
To make more clear my position:
I'm +0 declaring featurefreezing now for 2.3.0 (and branching)
I'm -0 branching only for a 2.3.0a3 release (I don't like branches for
milestones)
I'm +1 on identify a good release version (r406087 or newer) and try an
a3 release from a specific revision of our trunk.
My main priority (where I will spend most of my efforts) is
cleaning/refactorings that allow more modularity (I saw really many
developers have their own local branch of James, I would like to make
james more modular so they simply have to write modules and not branch
the code, because this will expand the developers community that are
able to run and work on the current sources).
Stefano
Noel J. Bergman wrote:
Stefano Bagnara wrote:
Starting new refactoring work I found out a new bug in the
MimeMessageWrapper/CopyOnWriteProxy things.
How do you prefer to proceed?
We don't really have a choice. The only option is
a. Should we branch from r400140, merge the above changes
and try an "a3" release?
and merge in the recent *FIXES*.
b. Should we otherwise try to release as alpha3 the current trunk
ABSOLUTELY NOT! The flurry of commits that change internal architecture,
configuration, concurrency, etc., without any prior proposal or discussion,
would be exactly the kind of thing that prevent a release if we work from
trunk.
I don't know if we want build_2_3_0_A2 or the JM14 variant, so would you
please svn cp the correct tag to branches/v2.3? We can work on the release
there. Trunk can be considered for v2.4 and later.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
