Re: Countdown to branch?

Mark Gilbert wrote:
>
> This is not what you said when the idea of basing branch on bugs was
> discussed not more than a few days ago, or when I offerred you
> assistance with a branch if you needed it. What has me "peeved off" is
> that your position has so rapidly changed, but I don't see any solid
> technical reasons for it, just emotional raves.

As for the question of a private branch, its not about your assistance
(the offer of which I do appreciate). The point is that I already have
two different branches to maintain locally, HEAD and ABIMATH, one of
which is not even in sync with the other; I really do not want another
one. I do not want it because I do not want to waste my time maitaining
it now and one day trying to merge it with all the other private
branches and the current head into the new HEAD. The point of the CVS is
to allow team development, which is what I want to do.

As for my unhapiness with continuation of this policy, the issue for me
is that of timescale. I could see the point of not branching immediately
after the release as a temporary measure allowing us to iron out early
hickups. But when this policy was first taken, I assumed (as did you,
iirc) that we vere talking about a relatively short time. But the
approach has not worked, for whatever reasons. The last time you
mentioned any timescale, it was pushed well into the new year. That is
bad news for me; I tend to be rather busy at work from early january
pretty much till mid june and would have like to get the groundwork for
the Pango graphics class into HEAD over the holidays in one big push. I
reckon I could have the class pretty much ready this week, had there
been a head, but considering the potential collision with Uwog's private
branch and the uncertainty about how long I would have to maintain this
privately, I decided that it was premature to start this work.

> the fact that the build would be broken (yours at that) if martin were
> to merge math into head at this very moment (not that he won't
> eventually)). If instead they are completed in branch, not polished or
> STABLE (that's where testing and 0ld sk00l dogfooding comes in to play),
> but completed and given a qa once-over in branch, they "do not block
> concurrent testing and development".

This makes sense for very radical alterations of the infrastructure
(which I am not needing to), not for day-to-day developing. Furthermore,
we are a very small team, so that if each of us has their private
branch, many bugs will go unnoticed until after the merge -- note how,
inspite of valiant effors by the QA guys, many bugs only surfaced after
the public release; I fear the multiplying of private branches will have
a similar side effect; how many bugs are there in the bugzilla for
uwog's private branch? How many bugs are there for ABIMATH? How many
people are fixing those bugs?

Personally, I would much rather have an unstable HEAD at this early
stage of the development cycle and have 6 months to find and iron out
the bugs, than have have 6 seemingly stable private heads and a couple
of months before the release to find and fix the problems in their
interaction.

> To keep the next milestone from taking 14 months and
> going out relatively untested, we keep mainline sane by declaring big
> new stuff that's going to need to be tested and by not putting in
> enormous new half-complete piles of code that cause more breakage than
> they fix. Regardless of when 2-2 is branched, this is the current
> state, with the purpose of keeping mainline not-completely-busted
> _after_ the 2-2 branch (before is pretty much a given). To make it up
> to the developers for taking away their playdays, we give them sandboxes
> in which to do whatever they bloody well want, which really minimizes
> any rain made by bugfixing on their play days. In many cases, it means
> _more_ light shines on coders' new features, because work in progress
> doesn't block mostly finished work from being tested or even going
> public.

There is no mostly finished work in HEAD; we have just releases. That
policy would have made sense in August, but not immediately after release.

> I personally, if it were my choice, would rather see users
> using 3 out of 4 new features by me in 6 months than 4 out of 4 in 12.

I heartily agree, but if the current policy continues, it could well be
that we will be branching in 6 months, not finishing 2.4.

> You think you're peeved, try seeing proponents of an idea turn into
> opponents on a whim, give no other reason, and propose taking
> undiscussed unilateral action in a meritocratic democracy to get their
> individual wants.

I was _never_ a proponent of a indefinite post-release feature freeze of
the HEAD; I was a proponent of a time-limited post-release freeze; the
two are not the same thing. Various people have repeatedly been asking
for a timetable for the branch; the 2.2-P1 query is not an answer,
because our lives outside of Abi are subject to the solar year, not the
bugzilla.

> -MG, having given up on any of his mail making it to the list, much less
> being read

I do read your mail, because I take seriously your views and appreciate
your contribution to the project.

Tomas
Received on Wed Dec 29 21:12:22 2004