Am Montag, den 29.05.2006, 11:40 -0400 schrieb Noel J. Bergman: > 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.
Hmm i also saw the trunk as developing tree. So i have no problems with big changes in the trunk if they make sense. I don't see any benifit from having thousends of branches ( in our case it whould be more like sandboxes). It maybe make things only dificulter. Cause the line numbers changed etc. So the merge is not so easy > > > 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 > Thats maybe right but the problem is that at some point the discussion seems to die always. Anyway why not change things and post it like done in the fetchmail code if its a bigger change. So anyone can have a look and give feedback. But like you see that also not work like aspected... Stefano ask at last what todo now. No answer since that. Same on maven2.. That not a critic on you .. its a critic on anyone.. also me. We must try to work better together. And not only make critic on each other. James is a great project but sometimes we take to long .. bye Norman
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil