* 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
