Re: 02-ac-shell-func.patch

[Paolo Bonzini]

> I guess we need to branch now :(

Branching is not forking, I don't see anything bad in branching while I 
would not be so crazy as to fork Autoconf!  As I see it, are three 
possibilities:

1) Do you want to release a 2.60 just for Automake 1.8?  If so, doing a 
branch for experimental features would be the best solution.

2) Do you think that these changes would imply an Autoconf 3?  If so, 
you should make a clear decision on where to stop with Autoconf 2.5x, 
branch, and develop Autoconf 3 on mainline.  A major release is hard 
because much more packages use Autoconf than at the time of Autoconf 2, 
of course.  But:
- the improved speed that shell functions give (it's proved, not 
theoretic) may make the hypotetic Autoconf 3 more palatable (or at least 
as palatable) than 2.50 was
- it is possible to take it very calmly
- it is possible to make *usability* improvements that are not feasible 
with the current framework (such as specializations)
- ...

3) Do you want to release a 2.60 for m4 2.0?  If so, Gary recently wrote 
on the libtool mailing list that you'll have to wait much before m4 
stabilizes on all the OSes on which Autoconf should run.  Modules are 
still one of the most poorly tested features in libtool, as useful as 
they are.  In this case, I'd not go with a branch at all, or do the same 
as 2) above.

Honestly, I do not understand your position very much.  I firmly believe 
you were right in exposing quoting errors in Autoconf 2.50; and I know 
that you also were much against the changes in Bison to handle omissions 
in the infamous trailing semicolon. But now it looks like you want 
Autoconf to freeze and fear any improvement to it.  Not a flame, you may 
have perfectly good reasons and even lack of free time can be one of 
them (maybe the one that I would understand the most...).

I do understand that you want Autotest to lead on the introduction of 
innovations, but it is too little used for this to be possible.

Paolo