Norman Maurer wrote: > > > 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-merg > er-trunk/tes > > ts/ > > > http://svn.apache.org/viewvc/james/server/tags/pre-v2and3-merg > er-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..
What I said about fetchmail holds for Maven 2 too. I'll try this another way. For 2.2.x code, if it ain't broke, don't fix it. We will never achieve fast turn around of incremental releases if we don't take this approach. More revolutionary changes should be saved for major versions. I count both the Maven and Fetchmail changes in this category. Regarding the Maven changes, as I previously said, having given Alan commit priveleges to demonstrate how we might Mavenise, why not give him sometime to comeback with some results and evaluate them? > > 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 .. And sometimes we forget that deciding to do nothing is sometimes for the best. Cheers -- Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
