From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludo@gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Newsgroups: gmane.lisp.guile.devel Subject: Re: 1.8 =?utf-8?B?4oCYc2VuZOKAmQ==?= bug + re-engagement Date: Mon, 24 Sep 2012 22:27:45 +0200 Message-ID: <87r4prkvy6.fsf@gnu.org> References: <87txvs2wx7.fsf@zigzag.favinet> <87mx1jqcbp.fsf@gnu.org> <87wqzp15k4.fsf@zigzag.favinet> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1348518478 31013 80.91.229.3 (24 Sep 2012 20:27:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 24 Sep 2012 20:27:58 +0000 (UTC) Cc: guile-devel@gnu.org To: Thien-Thi Nguyen Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Sep 24 22:28:01 2012 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TGFG1-0002Kn-KJ for guile-devel@m.gmane.org; Mon, 24 Sep 2012 22:27:57 +0200 Original-Received: from localhost ([::1]:59044 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGFFw-0000iM-P6 for guile-devel@m.gmane.org; Mon, 24 Sep 2012 16:27:52 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:34349) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGFFu-0000i8-4y for guile-devel@gnu.org; Mon, 24 Sep 2012 16:27:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TGFFs-00065m-M3 for guile-devel@gnu.org; Mon, 24 Sep 2012 16:27:50 -0400 Original-Received: from xanadu.aquilenet.fr ([88.191.123.111]:54277) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGFFs-00065J-CB for guile-devel@gnu.org; Mon, 24 Sep 2012 16:27:48 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by xanadu.aquilenet.fr (Postfix) with ESMTP id 98CEA9BD1; Mon, 24 Sep 2012 22:27:46 +0200 (CEST) Original-Received: from xanadu.aquilenet.fr ([127.0.0.1]) by localhost (xanadu.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKo+75S8v0Fd; Mon, 24 Sep 2012 22:27:46 +0200 (CEST) Original-Received: from pluto (reverse-83.fdn.fr [80.67.176.83]) by xanadu.aquilenet.fr (Postfix) with ESMTPSA id 876A5972B; Mon, 24 Sep 2012 22:27:45 +0200 (CEST) X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 3 =?iso-8859-1?Q?Vend=E9miaire?= an 221 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Key-ID: 0xEA52ECF4 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 83C4 F8E5 10A3 3B4C 5BEA D15D 77DD 95E2 EA52 ECF4 X-OS: x86_64-unknown-linux-gnu In-Reply-To: <87wqzp15k4.fsf@zigzag.favinet> (Thien-Thi Nguyen's message of "Thu, 20 Sep 2012 10:06:51 +0200") User-Agent: Gnus/5.130005 (Ma Gnus v0.5) Emacs/24.2 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 88.191.123.111 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:14911 Archived-At: Hi! Thanks for the update! Thien-Thi Nguyen skribis: > > i'd like to apply the fix myself (in the savannah repo), onto > > =E2=80=98branch_release-1-8=E2=80=99. > > Yes, please do! Can you apply it to stable-2.0 as well? > > Sorry, no; i lack sufficient bandwidth. OK, I=E2=80=99ll 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 =E2=80=98ttn-back-in-the-saddle=E2=80=99 for review? > > Makes sense, yes. > > OK, just pushed. I await your review. commit ee70ab60d0cf2f995b8ec513024a309610f3cb78 Author: Thien-Thi Nguyen Date: Wed Aug 22 14:51:33 2012 +0200 Rename configure.in to configure.ac, twice OK. commit 04d7f4a80fb84a7333bb58c831591a59f42ab59b Author: Thien-Thi Nguyen 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=E2=80=99m not sure I can reasonably commit to keeping track of each single commit that needs backporting, so I=E2=80=99d be happy if you would volunte= er, at least for this kind of simple patch. WDYT? commit 4bfdc6b88ea7a794ee7dac87e4f9fe71c3c064b1 Author: Thien-Thi Nguyen Date: Thu Aug 23 17:26:10 2012 +0200 Delete EOL whitespace; nfc Hmm, that reminds me of a discussion we had before. That=E2=80=99s fine on= ly as long as it doesn=E2=80=99t prevent merges. How would Git handle that? commit 4099d14b93fc60ff6c8bd0d3f409bf30772d939f Author: Thien-Thi Nguyen 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 Date: Wed Aug 22 18:16:23 2012 +0200 configure, int: Remove EOF "Local Variables" block; nfc OK. commit b3ee8403f89b21b1f9bda7fa93ef43861726fe5e Author: Thien-Thi Nguyen 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 Date: Thu Aug 23 18:09:17 2012 +0200 Delete EOL whitespace; nfc As above. commit 60a29ffea0b596ae19b3a5bafbcc47bfec50b3b9 Author: Thien-Thi Nguyen 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 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 =E2=80=98stable-2.0=E2=80=99, 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 =E2=80=9Cnoise=E2=80=9D on the commit list. So as a rule of= thumb, I=E2=80=99d 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=E2=80=99m happy with =E2=80=9C; nfc=E2=80=9D. > Anyway, i see 1.8.8 tarball does not even include a proper ChangeLog, so > that's an opportunity to backport the =E2=80=98gen-ChangeLog=E2=80=99 stu= ff... Indeed. > Other ttn-style stuff: no EOL whitespace, use SPC for indentation, > strict EOF "ends here" comment maintenance. There=E2=80=99s a couple of .dir-locals.el in stable-2.0, to use space for indentation in Scheme code. For the rest I don=E2=80=99t care. I have =E2=80=98show-trailing-whitespace=E2=80=99 set, FWIW, but again, few= er whitespace-cleanup changes is better, as far as I=E2=80=99m 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=E2=80=99d find it more important to help fix any issues that pr= event > 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=E2=80=99s forward-lo= oking 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=E2=80=99.