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]
