Am Montag, den 29.05.2006, 18:04 +0200 schrieb Stefano Bagnara: > 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.
Im sad to read this but i can really understnad what you feel. > > 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. That exactly what i thought. Trunk is for development and branches for releases.. isn't it ? > > 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 Bye Norman
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
