Noel J. Bergman wrote: > > Norman Maurer wrote: > > Noel wrote: > > > Stefano wrote: > > > > 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. > > > 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. > > As you suggest, we want development to happen actively within source > control, so that people can see the changes as they happen. > The fetchmail > code might have been a good example of when to use a branch, > since it was > relatively isolated, and would have been easy to merge in > afterwards. Steve > wasn't saying that the changes were bad, he was saying that > the changes were > substantial, and without having good testing coverage, they > are very risky > to replace code in trunk that is generally considered to be working. > > > James is a great project but sometimes we take to long > > Yes. And one of the things that held us up for a long time was making > changes that blocked our ability to get good releases out the > door. I'd > like to learn from that, and avoid a repeat. > Yes. And as I recall you were the one that put in much of the unpleasant grunt work to get us out of the mess. We really don't want anyone to have to go through this again.
In my experience, having more than one active development branch almost always ends in tears, even in more tightly controlled commercial endevaours. Its fine having a trunk and branches for past releases to which maintenance may be applied. For instance, after releasing 2.3 we branch it, the trunk becomes 2.4, we might backport critical fixes (no enhancements) applied to the trunk to the 2.3 branch. In my day job, we capture forward looking designs that we feel too radical for the current state of the trunk as design notes in Jira as issues against the next release. The notes include source code snippets, UML and text. Not too different to Stefano's approach. When the time comes for starting development on the next release, we evaluate the design notes for the release and either accept them, reject them, or defer them by moving them to the next release again. What we often find is that accepted design notes need a fair degree of redesign to integrate them with the current trunk, whic has evolved. This one time hit is much less work than trying to keep an alternate development branch in sync. with trunk development, especially when many designs tend to be darwined as evolutionary mistakes or misfits as the architecture evolves. In effect this approach is saying that the trunk is the one way ahead, we should nurture it carefully. There are lots of great people with great ideas that we want to capture, but the trunk isn't the place to do this. And finally, we are guaranteeing that at the end of every release cycle we will evaluate the pending designs. Hope this helps, -- Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
