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

[Stephen J. Turnbull]

>>>>> "Andrew" == Andrew Suffield <address@hidden> writes:

    Andrew> You also have to contend with the real reason for vendors:

    Andrew> Upstream authors are stupid.

    Andrew> The underlying problem is not that upstream authors can't
    Andrew> provide the necessary data, but that they make stupid
    Andrew> decisions.

I'm glad I didn't have to say that, but can quote Andrew.  ;-)

Most people, even computer professionals, did not grow up in Lake
Wobegon "where all the children are above average".  They're going to
make mistakes, be shortsighted, etc, etc.  Or have a bitter fork
resulting in multiple competing implementations, which multiuser
systems will want to have all of.

Or maybe they just have a life.

Ie, there's an essential problem here (cf. Brooks "No Silver Bullet"),
and all the c/b/i improvements in the world are not going to give a
single order of magnitude improvement because they don't attack the
essential problem.  I'd say that the underlying problem is free
software. :-)

That is, anybody can be an author, and they can have it their way, and
they're going to have it their way.  It is not at all obvious that
demanding that they sit down and think about how their stuff is going
to be reused, and by whom, and what that implies for design, is
worthwhile.  They need to learn a little bit about everything in order
to have a pretty good sense of what surprising applications their work
might have, and to make sensible preparations for that.  That's a lot
of learning, and it gets worse all the time; much easier to get a
doctorate and know almost everything about almost nothing, at which
point you can stop learning. :-)  At some point people have to decide
whether the old software they can make more portable is a more
important contribution than the new software they can write.  There
may be a bias toward new software, but there certainly is a point
where the answer from society's point of view is "stop rewriting and
switch to new stuff."

    Andrew> Alas, things are never that easy. This would only work if
    Andrew> all (or even a significant number) of upstream authors
    Andrew> understood and cared about the issues. In reality they
    Andrew> just don't want to deal with it.

Why should they deal with it?  Typically they are not very good at it,
through no special fault of their own.  Quite often the portability
stuff, both code and testing, is contributed by third parties and the
core maintainer doesn't have the expertise to deal with the platform
flakies, or the cross-platform scaffolding that might make things work
better.

    Andrew> Even proper use of auto* is usually beyond them - somebody
    Andrew> has to come along and fix it for them on occasion, and
    Andrew> it's usually the vendors who do this.

Vendors have to deal with platform issues all the time.  They get
pretty good at this.  Seems like an obvious division of labor to me,
except that you could wish things weren't _so_ divided.

    Andrew> As always, the problem isn't that you've got the wrong
    Andrew> kind of government. The problem is that you've got the
    Andrew> wrong kind of people. It's easy to blame the government,
    Andrew> but it really isn't their fault.

It's not obvious to me that a world full of Toms would be able to deal
with the problem.  Sure, starting from today's mess they'd make
enormous amounts of progress over the next decade, but then the rate
at which software was being produced would have accelerated enough to
get to the point where once again they couldn't coordinate conflicting
designs and produce new designs at the same time.

Then they'd have to invent Andrew!

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.