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]
