Re: [Gnu-arch-users] Managing changes to projects that use autoconf/automake with tla

[Tom Lord]

    > From: "Stephen J. Turnbull" <address@hidden>
    >Tom> You can arrange coordination with good tools.

    > Nonsense.  There is excellent reason to believe there are essential
    > limits, though I know of no proof.  Coordination without hierarchy
    > requires communication which is exponential in the number of
    > participants, or a market structure which free software inherently
    > foregoes.  Sure, you can design better structures for general
    > communication, but design implies hierarchy (ie, at least a central
    > architectural authority), and the ones I know of require some form of
    > central control.

Successful tools implement limited purpose control hierarchy.
Successful standards do, too.  Some obvious examples are programming
languages, the Linux kernel, and Apache.  Take the kernel, for
example: it has coordinated a lot of people who write device drivers.

All I'm saying about c/b/i stuff is that there's a need for improved
standards about the interface to projects' c/b/i system and that in
the absense of a hierarchical command structure from which to say
"Thou shalt support `make install' with the following meaning...."
the tactic to take is to build c/b/i tools that happen to implement
the standards but that are also good enough that a majority of core
projects choose, all on their own (well, with advocacy), to adopt
those tools in preference to auto* and other competing systems.

That has _already_been_done_ for a subset of c/b/i tools.  For
example, Python and Perl both have standard install processes defined
by tools that ship with Python and Perl.  No, not every package uses
those but a critical core does.  You don't need 100% adoption to
radically improve the situation over what we've currently got.

-t