Stefano Bagnara wrote: > 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.
And separately: > I temporarily will stop to commit in trunk until I will find the time > to clear up how many branches do we need > I thought that having a 2.3 branch and being committed to fix any bug > found on that branch would have been enough. Yes, that's great. For that release. What about the release after that? When would you like it, what would you expect in it, and how do you propose that we get there? Allowing us to manage that sort of change is the purpose for this discussion. I am not suggesting that you stop committing to trunk. And I would say that how many branches we have at any point in time depends upon what we're trying to do. We have the v2.3 branch, which we can use to get that release out the door. Fine. We have trunk. Trunk is being used for a variety of different changes of varying impact. You say that: > The trunk is not there for the release or for the mainstream users, the > trunk is there to work and should be used by people that work, to work. That may not scale if multiple people want to work on multiple changes on different timelines, but for now let's leave that question aside. Norman says: > 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 agree, but again with the caveat that big changes do mean more risk, more testing, and generally speaking, more time before release if we are serious about wanting releases to be stable and reliable. So a related question would be how should the release after v2.3 be made? Copy v2.3 to v2.4, and merge in pieces from trunk as necessary? For each release? Or do we want to try to keep trunk more stable (not unchanging, just making sure that we have confidence in what is in it), and work on the more pervasive and/or riskier changes in a branch before merging them back in? The solution, as I expect we all agree, is NOT to have a lot of branches, or at least not long-lived ones. As I said, this isn't about what you are doing, it is about how how we want to set ourselves up for managing change. So that we *can* making releases in the kind of timeframe that I believe we all want to have them. Because this is not a new problem, nor one that is caused by you. We have run into this problem before. Danny started making changes in trunk that in the end not even Danny wanted. Meanwhile, all of the Avalon changes were made in trunk. And other work was happening in trunk from other developers. And for a long time we spent a lot of effort for a while trying to copy changes between trunk and the v2 branch. In the end, that cost us a *lot* of time between releases. I'd like to avoid us having that problem again. Hence the topic: Managing Changes. So that we can all agree on how best to address the issues that we collectively face in moving forward *and* being able to continue making reliable releases. One approach might be that when we want to make a substantial change, we either discuss it first and get people to agree on making the proposed change directly in trunk; or we might create a branch, do the work, get a consensus, and merge the work into trunk. This approach might be particilarly effective when the changes are both substantial *and* relatively isolated, e.g., the recent changes on fetchmail. > how many mailing list message per line of code changed we want to require. Again, depends upon what changes are being made. When we replace the spooler, I would expect discussion. Fixing a bug in a mailet, less discussion. Total architecture of some components, more discussion. --- Noel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]