Re: Countdown to branch?

On Tue, 2004-12-28 at 10:43 +0000, Tomas Frydrych wrote:
>
> J.M. Maurer wrote:
> >
> > note: you can always create a branch to develop a new feature in, so you
> > can start right away...!
> >
> > Marc
>
> That is a real pain, and you of all people know it. We already have

        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. I'm always open to new
ideas, especially about how to keep mainline from going so completely
out of control that it's another 14-month untested release. I haven't
heard any. Which leaves either [A) Help the coders of risky new
infrastructure to develop their work in a sandbox where it won't
interfere with others or B) Give the only cvs write permissions to one
person and 'ban' others, leading to the inevitable fork of the project]
as means by which to release in less than a year something both more
stable and more featureful than the last milestone.
        I also wouldn't tell Marc what he knows, I think he knows what he
knows. He wouldn't be commending it if he didn't do it successfully
himself. His branch, making his patches themselves easy to test, is the
_only_ reason your recent off-pixel fixes in head have not significantly
interferred with his work, as well as the only reason that even when it
was largely incomplete and didn't even build on windows, it didn't stop
you from other development or sum1 from testing.

>
> ABIMATH branch for developing math and pango stuff, and your dbl units
> branch, and HEAD, which we are suppossed to treat as STABLE. How many
> more flipping braches do we need to get on with things? Really, we
> should have a STABLE branch and HEAD branch; I refuse to maintain more
> than two branches locally, or to have private branches in order to
> develop stuff that we agreed is to go into 2.4 (I can just imagine the
> pain when we try to merge half-a-dozen private HEADs).
> I agree with Martin that the present situation is most unsatisfactory,

        It sounds to me like you're putting words in Martin's mouth this time,
and I know that when people put words in my mouth, I certainly do not
like it. I heard "In addition I find I'm getting anxious", as an aside
in an email primarily serving as a request for the 2-2-P1,2-S+ query, as
well as recognizing the fact that the decision to branch should be
integrated with QA and not in spite of it (which is he is postponing
bugs that will require infrastructure not present in 2.2), and
encouraging other coders to help out with adjusting the blocking bugs as
need be.
        I also sounds to me like you are confusing isolated development of
highly intrusive overhauls with the delay in branching 2-2. Whether we
branch in one day or one week or one month, if we're to make another
milestone in good time after that, and one which is well-tested enough
to be not disastrous for our users, mainline has to stay under control.
Not STABLE, but under control. Highly intrusive overhauls happening
directly in HEAD is the frequent cause of other developers being
handicapped for working on other things, and QA being unable to test
(things like "It's so unstable I can't discern a bug", and for example
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". On that note, I ask again why
there was no objection when I proposed this before, and in fact
widespread support, including amongst the same people (ie, you) that
oppose it now? Or, disregarding that question, have you had a more
enlightening reflection on how to avoid the mistakes and bad situations
of the past, so that we don't have to wait another 14 months for 2.4,
and 2.4 is actually more usable than 2.2? Because I'm far more open to
ideas than I am to rants, and I have not heard any of the former.

> peeved off and seriously tempted to tag and branch at this very moment
> so he can commit stuff into head that belongs there.

        The tradeoff is between stable releases and developer playdays, it
always has been. 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. 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.
But I have yet to hear other ideas, other lessons learned from the past
proposals that would take care of the situation. I would like very much
to hear some.
        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.

-MG, having given up on any of his mail making it to the list, much less
being read
Received on Wed Dec 29 18:35:23 2004