On 9/14/06, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
I will read and reply to the various comments later, but I want to put some
figures into the picture.
$ du -hs branches/v2.3/src/java trunk/src/java
13M branches/v2.3/src/java
15M trunk/src/java
$ svn
diff --old=https://svn.apache.org/repos/asf/james/server/branches/v2.3/src/j
ava \
--new=https://svn.apache.org/repos/asf/james/server/trunk/src/ja
va >diff.txt
$ 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.
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.
I am having a hard time understanding this. Do you say, that all
commits in current trunk since branching have a silent -1 from you?
What specific changes do you object?
I think there are enough eyeballs constantly monitoring trunk, which
does not mean to _release_ it blindly without testing. But having an
audit on a commit-per-commit basis makes no sense, since many of them
where applied to 2.3 branch anyway. The rest simply has to be tested.
This is also the reason for me to propose following our original
reasoning when branching 2.3 (read: not 2.x-branch, but 2.3.x-branch):
This is the maintainence branch where we apply bugfixes for 2.3.x.
Fixes are isolated, well tested and thus a branch is maintainable.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
