Re: Making Autoconf 2.70 happen in the near future

[Bob Friesenhahn]

On Tue, 10 Mar 2020, Zack Weinberg wrote:
> > The git commits are more a factor of who has the personal ability to
> > make commits than whether the commits are the most important changes
> > needed.
>
> What you say is true, but I only have a finite amount of time to put
> into this, and I currently think that additional testing will be a
> more effective use of that time than finding unreviewed patches within
> the past eight years' worth of mailing list archives.  To put it
> another way, would you rather see me find unreviewed patches or would
> you rather see me run a Debian archive rebuild with a 2.70 release
> candidate as /usr/bin/autoconf?

Running a Debian archive rebuild will produce useful information but 
Autoconf is fundamentally a portability tool and testing it on one of 
the best supported and most popular GNU/Linux distributions does not 
demonstrate portability.

The concern is that patches for interesting "new" systems may have 
been missed, or that less popular systems and targets may have changed 
their behavior in the mean-time, or that non-portable dependance on 
GNU tools has crept in.  It would be particularly unfortunate 
if the system or target which was missed is based on free software and 
that patches were submitted.

Hopefully people using less popular systems have not given up on 
Autoconf and will notice this discussion.

Bob
--
Bob Friesenhahn
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt