Re: wish list

[Ralf Wildenhues]

* Paolo Bonzini wrote on Mon, Mar 30, 2009 at 07:41:24PM CEST:
> Eric Blake wrote:
> > Here's links to several issues that I have kept flagged in my inbox, but
> > which have not been high enough priority for me to attempt any patches.  I
> > personally don't think any of them are worth holding up the release of
> > beta 2.64, but would like to address some of them before declaring a
> > stable 2.65 (or 3.0?) release.
> 
> I'm a bit more draconian than you.  All of those issues (almost all) are
> preexisting, or improvements.

FWIW, I agree with Paolo in that none of these issues are regressions
nor show-stoppers; that doesn't imply that I consider anyone draconian
around here.  ;-)

> I could not reproduce
> http://lists.gnu.org/archive/html/autoconf-patches/2008-11/msg00126.html

This has been addressed since.

> and of all issues you pointed out, only that one and
> http://lists.gnu.org/archive/html/bug-autoconf/2008-12/msg00030.html
> seemed worth being fixed in a *stable* (2.64 or 3.0) release.

The following two things cause minor headaches for me:

- your patch to not run the testsuite in parallel will not prevent the
user from shooting herself in the foot when /bin/sh happens to be dash.
More precisely, the turning off doesn't happen in lib/autotest/general,
which means that
  make check TESTSUITEFLAGS=-j8

will cause parallel execution no matter what the shell.  That's probably
ok, as it allows the more adventurous to try things out, but maybe BUGS
can be a bit more explicit in that the above isn't wise with all shells.

- the new AC_REQUIRE warnings may not be easy to solve in general.
Consider the following situation: you require two macros, both from
different third parties (a third and a fourth party?).  One requires
a common macro, say AC_PROG_CC, another expands it.  You cannot easily
solve this situation.  It might be a bug, but then again, it doesn't
have to be: it can depend upon the semantics of the common macro
whether this is a problem.  Sometimes multiple invocation is actually
intended, be that because the configure.ac author plays tricks with
unset, shell flow of execution constructs (loops, branches), etc.

Anyway, the latter issue really can be quite hairy.  I guess we'll see
what happens, but I do think we shouldn't assume more than absolutely
necessary.

> So in my plan, do we think that an alpha.gnu.org release would add
> anything?  Would anyone actually use it?  If no, let's go with a stable
> release now.  If yes, let's do 2.64b and cut a branch to release
> 2.65/3.0 from in a month or two (no more - hard deadline); in the
> meanwhile new features can be worked on in master.

Are we in this situation right now (just curious)?  IOW, are there
changes waiting for a free tree?

Cheers,
Ralf