Dave Love writes: > "Stephen J. Turnbull" <[EMAIL PROTECTED]> writes: > > > You don't consider tool-chain-induced corruption serious? I certainly > > do. > > Like the autoconf maintainers, I don't consider the bulk of autoconf > bugs serious (and I'm quite familiar with it). No evidence of serious > problems is apparent, just FUD.
I asked that you display your standard, not that you assert your expertise. You are not an expert on the cost of bugs to me and my users. As for "FUD", indeed, that's precisely the issue! I fear autoconf upgrades, I'm uncertain where the bugs will be, and I doubt that I'll experience a painless autoconf upgrade in this decade. Not only is this FUD justified by experience, but I don't really think there is a way to avoid it, given the heuristic nature of much of autoconf. Thus, I would like to make autoconf upgrades less frequent. So I asked that Darcs strongly consider not including patches that induce their users, some of whom are my users, to install more recent versions of autoconf. > > "First, do no harm." Even before DTRTing. > > Please don't be insulting. What's insulting about quoting the Hippocratic Oath? Like medicine, the autotools are a huge pile of interacting heuristics. The behavior of the scripts they produce is incredibly complex. My experience has been that an autoconf upgrade is a regression waiting to happen; every app that requires an autoconf version greater than mine is therefore a threat to me. I acknowledge that that harm may be in the interest of the greater good; I do not yet concede that it is. > The `AFAIK' is wrong -- look at the patch. I acknowledged that by putting DTRT second -- high priority, but not top priority. > > XEmacs has already dealt with the known problems, obviously. > > Then I guess XEmacs cocked something up; Now who's being insulting, on the basis of something you know nothing about, it would seem? *Of course* XEmacs cocked something up -- you have no choice when using autoconf with a complex legacy application. Our experience has been that *every* upgrade of autoconf *silently* invalidates some code we introduced years before. (Of course, -Wobsolete -Wsyntax also complains about many others, but it misses many.) We've tried pinning the version of autoconf, but that's also not a very good strategy precisely because every version has unique requirements, so that imposes pain on the many whose other software AC_PREREQs an upgrade and thus they would need to maintain multiple autoconf installations. Nor does autoconf itself support pinning. > Emacs development code actually requires autoconf 2.61. Emacs is a GNU project. I don't question that delegating autoconf to check conformance to GNU standards is a win there. Interestingly enough, Emacs *prerelease* code also requires a patch to autoconf 2.61. > There doesn't seem to be a relevant bug report against autoconf > from XEmacs anyhow -- I actually looked. Why would you expect one? When our hacker went to look, they were known issues. As was the Emacs problem. Those fixes are already in the autoconf repo, one is even in 2.61. But AFAIK "HEAD" is not a valid argument to AC_PREREQ, nor should it be. As is true for almost all free software, every autoconf public release is a beta. Popular projects that *require* the most recent release have a strong tendency to induce the whole user community to be beta testers. That may not be wrong, but it's question-able, and I'm questioning it. Eg, by comparison, although GCC's current beta release is 4.2.0, the recommended release used in Debian "sid" is 4.1.2, Debian stable installs 4.1.1, MacPorts 4.0.4, Mac OS X 4.0.1, and my Gentoo Linux box which I update religiously still defaults to 3.4.6 (ie, there are distros that don't consider 3.4.6 "too old to be default" --- I'm sure a recent Gentoo install would default to 4.x). I wouldn't hold autoconf strictly to that standard, but it's a relevant comparison. Autoconf is part of the toolchain, and many of the reasons that apply to conservatism vis-a-vis compilers apply to other parts of the toolchain. > This pain seems to be a figment of the imagination, There you go again, denying *my* pain and that of *my users*, and claiming *we're* crazy. The pain to third parties is real. The question is whether the incontestable improvements are worth the pain imposed on others. Like you, I will leave that judgment up to the Darcs maintainers ... having pled my case. The plaintiff rests. _______________________________________________ darcs-devel mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-devel
