Hi! Thanks for the update!
Thien-Thi Nguyen <t...@gnuvola.org> skribis: > > i'd like to apply the fix myself (in the savannah repo), onto > > ‘branch_release-1-8’. > > Yes, please do! Can you apply it to stable-2.0 as well? > > Sorry, no; i lack sufficient bandwidth. OK, I’ll do it if nobody beats me at it. > > [...] > > 60a29ff [...] libguile: Fix bug: Don't expect 'send' [...] > > d70f9c8 [...] > > > > Note that the fix is the penultimate change (60a29ff). How about i > > push this to ‘ttn-back-in-the-saddle’ for review? > > Makes sense, yes. > > OK, just pushed. I await your review. commit ee70ab60d0cf2f995b8ec513024a309610f3cb78 Author: Thien-Thi Nguyen <t...@gnuvola.org> Date: Wed Aug 22 14:51:33 2012 +0200 Rename configure.in to configure.ac, twice OK. commit 04d7f4a80fb84a7333bb58c831591a59f42ab59b Author: Thien-Thi Nguyen <t...@gnuvola.org> Date: Wed Aug 22 15:01:34 2012 +0200 configure, int: Add abstraction: CONFIG_SCRIPT OK, in principle. Perhaps CONFIG_SCRIPT could take a list of files and m4_foreach on them? However, this kind of patches *must* be applied to stable-2.0 as well, to avoid gratuitous divergence. I’m not sure I can reasonably commit to keeping track of each single commit that needs backporting, so I’d be happy if you would volunteer, at least for this kind of simple patch. WDYT? commit 4bfdc6b88ea7a794ee7dac87e4f9fe71c3c064b1 Author: Thien-Thi Nguyen <t...@gnuvola.org> Date: Thu Aug 23 17:26:10 2012 +0200 Delete EOL whitespace; nfc Hmm, that reminds me of a discussion we had before. That’s fine only as long as it doesn’t prevent merges. How would Git handle that? commit 4099d14b93fc60ff6c8bd0d3f409bf30772d939f Author: Thien-Thi Nguyen <t...@gnuvola.org> Date: Thu Aug 23 17:43:47 2012 +0200 configure: Dose configure.ac w/ "proper" m4-quoting OK, but must also be adjusted & applied to other branches. commit 037b7f6a16d06073ae2b1f5cd3ad2588b2685455 Author: Thien-Thi Nguyen <t...@gnuvola.org> Date: Wed Aug 22 18:16:23 2012 +0200 configure, int: Remove EOF "Local Variables" block; nfc OK. commit b3ee8403f89b21b1f9bda7fa93ef43861726fe5e Author: Thien-Thi Nguyen <t...@gnuvola.org> Date: Thu Aug 23 17:15:32 2012 +0200 configure, int: Add more 'AC_LANG_PROGRAM' calls OK, needs porting to other branches. commit ccb98a34d4871f356e7673e86be63b507e91fa8d Author: Thien-Thi Nguyen <t...@gnuvola.org> Date: Thu Aug 23 18:09:17 2012 +0200 Delete EOL whitespace; nfc As above. commit 60a29ffea0b596ae19b3a5bafbcc47bfec50b3b9 Author: Thien-Thi Nguyen <t...@gnuvola.org> Date: Thu Aug 23 18:17:08 2012 +0200 libguile: Fix bug: Don't expect 'send' string to be writable OK. commit d70f9c8869aa46898e52124c4e42d0d0059210d7 Author: Thien-Thi Nguyen <t...@gnuvola.org> Date: Thu Aug 23 18:17:45 2012 +0200 Update years in copyright notice; nfc Currently we enumerate years. To use ranges, I think we have to update our README to allow that. In ‘stable-2.0’, README says: See the LICENSE file for the specific terms that apply to Guile. Note that for any copyright year range specified as YYYY-ZZZZ in this package, the range specifies every single year in that closed interval. Can you apply that as well? In general, I find that copyright year updates, whitespace cleanups, M4 quoting, and the likes may be good ideas in principle, but they also cause a lot of “noise” on the commit list. So as a rule of thumb, I’d try to keep to signal-to-noise ratio good enough. > Yes. For 1.8.9, i plan to: > - audit libguile for this (writable/read-only string) class of bug > - add tests > - back/forward-port tests > - back/forward-port docs Great. > Further 1.8 releases will be similar, the goal being to transition from > point-fixes to systemic improvements. On the side, i plan to improve > the build environment (makefiles / configure.ac / doc-mangling). OK. > For example, the TITLE in a ChangeLog entry (in git jargon, the commit's > "subject line") has no prescribed format. Guile HACKING refers to this > only as "1-line description of change" (pretty loose), whereas ttn-style > is to use a certain format, the germane part of which is the trailing > "; nfc" to indicate that the change does not warrant a ChangeLog entry. > (NFC stands for non-functionality -- i.e., cosmetic -- change.) I’m happy with “; nfc”. > Anyway, i see 1.8.8 tarball does not even include a proper ChangeLog, so > that's an opportunity to backport the ‘gen-ChangeLog’ stuff... Indeed. > Other ttn-style stuff: no EOL whitespace, use SPC for indentation, > strict EOF "ends here" comment maintenance. There’s a couple of .dir-locals.el in stable-2.0, to use space for indentation in Scheme code. For the rest I don’t care. I have ‘show-trailing-whitespace’ set, FWIW, but again, fewer whitespace-cleanup changes is better, as far as I’m concerned. > > I imagine if this particular fix goes smoothly, i will be motivated > > to continue w/ this kind of maintenance work, where the focus is on > > continuity and stability (perhaps likewise showing 1.6 and 1.4 some > > love, as well). > > Hmm, I’d find it more important to help fix any issues that prevent > current 1.8 users from switching to 2.0, FWIW. > > Well, that's why i'm here -- to do the non-important-for-ludo stuff > (that happens to be important for others). I think the more you move > your mind away from "switching" (XOR) and towards "stepping" (XOR, brief > (or not) IOR, XOR), the more you will see value in what i do. As I think this very review shows, the problem is not much whether I care about it (and I actually do), but whether we can handle the bandwidth increase without compromising on the project’s forward-looking activity. IOW: I find it important to maintain 1.8, but not at the cost of reducing hack power on 2.0/2.1. Thanks, Ludo’.