Sorry. I can't keep up with this. This, in part, offend me: I would
accept this if I was one of ten committers actively working and if my
work introduced more problems than the ones fixed.
I'm too busy now to try again understanding this. I temporarily will
stop to commit in trunk until I will find the time to clear up how many
branches do we need and how many mailing list message per line of code
changed we want to require.
I thought that having a 2.3 branch and being committed to fix any bug
found on that branch would have been enough. I obviously misunderstood
this and I need to plan things differently.
I will try to come back with clear things to Vote, to avoid future
misunderstandings.
Stefano
Noel J. Bergman wrote:
Stefano wrote:
maybe I should start working on a branch [instead of trunk]
At the moment, I don't think so, but in the bigger question, it depends upon
what we are doing. Some of the changes being made are going to push release
dates for trunk back further and further, whereas others won't. Steve's
comments about Fetchmail, for example, weren't that the changes might not be
good ones, but that they are likely to push out release dates for trunk.
Every change has a risk and a cost. Every change. The more major the
change, and the more pervasive its effect, the more the risk. The more
risk, the more testing that should be done. And hopefully the greater the
benefit, or there is little point to making them.
Making changes changes schedules. Many of the changes you are making are
fine, but they change core parts of JAMES, which means more risk.
Fortunately, we have more testing coverage, and that is helpful, but these
changes still entail higher risk than isolated changes effecting single
components.
A related question is what belongs in trunk. I would say that it should be
the mainstream development. When we did the branch merger, we intentionally
merged only the actively used, mainstream, code into trunk. So, as you
discovered, there are other things, such as proposals, testing code, and
other things, that weren't active and weren't merged. Not everything is in
trunk, and people should be aware of where those things are in case they
want to start working on those parts, and make it suitable for trunk.
For example:
http://svn.apache.org/viewvc/james/server/tags/pre-v2and3-merger-trunk/tes
ts/
http://svn.apache.org/viewvc/james/server/tags/pre-v2and3-merger-trunk/pro
posals/
Bernd might want to look at the testing code, for example, although he may
have surpassed it in all cases.
Personally, I'd see making major changes in branches, and merging
afterwards, so that trunk can be kept more stable while those changes are
being made. I don't know how others feel.
We can't take weeks and dozen of messages for each single commit.
Depends upon the nature of the change. Weeks and weeks of active
discussion? Might be quite useful. Weeks of silence? Not so much. Dozens
of messages on something? I'd expect nothing less for some types of
changes, althought I would also expect development to start at some point
during the discussion.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
