Re: [Gnu-arch-users] Status of global and tree aliases

[Tom Lord]

    > From: Colin Walters <address@hidden>

    > On Tue, 2004-07-20 at 16:05 -0700, Tom Lord wrote [to jblack]:

    > > You've also repeatedly expressed some hostility towards furth.  I'm
    > > quite puzzled by that and am starting to wonder if this is just some
    > > kind of personality conflict or whether you have a good reason to be
    > > hostile.  So far as I know, you know almost nothing about furth.
    > > Moreover, adding furth to tla can, in the medium term, result in less
    > > and simpler code overall -- that should be fairly obvious.  It's
    > > unclear to me why you are so hostile to furth so perhaps you could
    > > explain your engineering reasons so that they can be either refuted or
    > > conceded to.

    > To me the engineering reasons seem obvious.  In large part it's a
    > question of resources.  You have spent a whole lot of time designing new
    > languages, VMs, etc, when there is still an outstanding need for a
    > security release of tla.  On top of that there are a large number of
    > outstanding changesets simply waiting to be reviewed from a number of
    > people like Aaron, Johannes, Miles, and me.  On top of that there are
    > serious bugs that need to be fixed, like the id corruption bug, the
    > inefficiency of "tag", race conditions in "tla add", etc.  This whole
    > discussion is just a big waste of time that could be much more
    > productively spent on those real issues that have been reported by
    > actual users.

It is a question of resources, you're quite right.

That is why people like asuffield have stepped forward to help
implement the proper solution: tools that will streamline the
processes and also prevent any one person from being a bottleneck.

That is also a large part of why I bumped up the priority on the
issues formerly known as "itla" with the work beginning with the
FEATURE PLAN posts and continuing in furth.

It's a classic case of having a problem X and a meta-problem Y such
that the absense of a solution for Y is most of the cause of X.
If that situation is expected to keep recurring, and you have only
resources to work on X -or- Y, then Y is the problem to work on.

If you want to provide at least one additional full-time programmer
for arch, then we can work on both X and Y at the same time.

-t