Noel J. Bergman wrote:
I will read and reply to the various comments later, but I want to put some
figures into the picture.
[..]
$ ls -l diff.txt
-rw-rw-r-- 1 noel noel 2056010 Sep 14 13:19 diff.txt
So there are 2MB worth of differences in the Java code between trunk and
v2.3. Some of the 2MB are overhead in the diff format, some are license
headers, some are refactoring, some are more substantial and functional
changes.
Ante scriptum: This 2MB things MEANS NOTHING to me (if not the RAM
leaked by your server :-P ):
a. 1MB is the header update patch (svn diff -r426006:426007
https://svn.apache.org/repos/asf/james/server/trunk/src/java
>diff-license.txt)
b. 466K are in the smtpserver package
c. Most of other changes are small refactorings (where code has been
moved in another class so it creates big diff) and new classes (we added
new mailets, and a lot of remotemanager/jmx stuff). As an example 45K of
this remaining bytes (almost 10%) are the new mailets I committed 3 days
ago: new mailets (even if they may be buggy) are much less dangerous
than the fastfail change.
That said I hope you now have a better overview of what we are talking
about and that you understand that MOST code changes are in the
smtpserver package that is the one now under branching/redesign.
I am *not* willing to effectively accept blindly changes of roughly 15% (and
that's only the current stuff, not including major new development) of a
stable codebase. I *am* willing to go through it with everyone, change by
change, and decide what is reasonably safe to add in the short term, and
what needs much more attention for a later merger.
Why blindly? I always check what we commit in trunk: imho trunk is not
special. If you never looked at it then feel free to start reviewing it,
but the fact that you never looked at it doesn't mean that we did the
same. I don't feel blind about trunk: in fact I tried to reproduce in
trunk every single bug we found in 2.3 and I always fixed it in trunk
before checking wether the solution could be applied to the branch.
I'm not ready to start an issue by issue, commit by commit discussion
for a next-minor release.
I trust your judgement about it, so feel free to do this with Vincenzo
and anyone else that want to be part of this selection work. My reply
now would be either "let's wait, we are not ready to branch" or "+1 to
include every single patch, but we'll need to decide what to do with the
2 handlerchain trees" so it doesn't make sense that we work *together*
for this.
I hope you won't need 2 months to review the 2MB or your roadmap will
have some delay (just joking ;-) ), so feel free to review and to add
any useful consideration to this thread!
Sincerely I suggest you to finish the fastfail/handlerchain stuff before
starting this selection work as this is the bigger of the steps in your
roadmap and If I understood your roadmap fastfail is the key component
of the "next-minor" release.
I hope you will accept the "next-minor" / "next-major" proposal and that
we are ready to start.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
