Re: Countdown to branch?

Hi Mark,

> Mark Gilbert wrote:
>
> The fact that you can't simply commit it to HEAD right now is not the
> fault of using a branch for something that, at least at its start and
> for quite some time, would cause severe disruption of other development
> and testing.

No, it is the fault of there not being a development branch.

> It could also be argued, quite futily, that if it's too simple and
> isolated to warrant a branch, it is simple enough to be a standing patch
> in bugzilla until we've branched

That is how things where done before there was cvs, and why cvs was
invented. I have had the 'priviledge' of maintaining a patch for a
feature for several months when I first got involved with AW and have no
intention to do that again. The suggestion is riduculous, I hope that is
what you meant by futily.

> The point of there being a branch in CVS is that it isn't private at
> all, it's there for others to pound on, without being in the way.

Do you regularly pound the ABIMATH branch? Do you regularly pound the
DOUBLE branch? If I create a branch for my stuff, will you maintain a
local copy of it too? If the answer to any of these is 'no', then the
fact that they are not formaly private is of little relevance.

> Right, well, again, I don't want to mix the usage of branches for
> infrastructural changes with the delay of branching 2-2. The latter has
> naught to do with the former, the former only serves a convenient
> secondary purpose for those most severely affected by the above latter.
> (see also: kernel.org)

Actually, the latter has everything to do with the former if you are
telling me 5 weeks after 2.2 release that I have to create a private
branch to work on 2.3.

> you can see that I intended not for the use of
> feature-branches to substitute for branching STABLE, only for the
> purpose of keeping mainline sufficiently in control to not block
> concurrent testing and development.

I am glad to hear that, but that is not how the current policy is
working out.

> I'm NOT insisting on a STABLE HEAD

Well, actually you are. As long as the stable is not branched there
cannot be API changes; as long as there cannot be any API changes, the
HEAD _is_ STABLE.

> The problem is that neither you nor I nor martin nor Scrambler is going
> to spend the next 6 months in HEAD, once it's branched, just fixing
> bugs, that's why we branch, to make an excuse to forget about fixing
> bugs for six months (-:

Yes, I acknowledge there was a problem in the previous development
cycle, but the solution to that is not to prevent us from working on new
stuff by refusing to branch. The core developers have to take ownership
of the STABLE, not just of HEAD (but that cannot be forced on us) and we
have to agree a fixed and reasonably limited features list for 2.4 _now_
  (I have been asking for nearly two months now, but the discussion got
completely out of hand).

> But again, I'm _not_ suggesting that HEAD be STABLE through to June.

No, but from what was initially expected to be 4 weeks at most; it has
been 5 weeks since 2.2.0 has been tagged, and you are now talking about
another 7 weeks; that is another 3 months of nothing but bugfixing on
the top of the the 6 months we have already done.

> I also did not expect for there to be a few weeks of almost complete and
> total dead wrt commits. I was hopeful that a Christmas-present branch
> could be made that would still reflect the state in bugzilla. Wrong
> about that one, obviously, but you can see I was not in favor of
> lifetime lock-down.

I believe that the slowdown is the direct consequence of the
not-branching policy, which has created a serious morale problem; it
might be technically sound, but it did not take the human factor into
account. We have worked real hard for 6 months to get 2.2.0 out of the
way. Nobody has the motivation to just fix bugs any longer, I think it
is as simple as that.

> A point which while true, is only relevant given the premise that new
> features take precedence over fixes for the mostly especially bad bugs
> that are therein described.

No, I am not making that assumption. I want to be able to both fix bugs
in 2.2.x and work on features for 2.4. You are assuming the two are
mutually exclusive.

Tomas
Received on Thu Dec 30 00:50:08 2004