guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 1.8 ‘send’ bug + re-engagement


From: Thien-Thi Nguyen
Subject: Re: 1.8 ‘send’ bug + re-engagement
Date: Thu, 20 Sep 2012 10:06:51 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux)

() address@hidden (Ludovic Courtès)
() Sat, 25 Aug 2012 16:24:26 +0200

   > Looking to move WIKID[0] out of the Guile 1.4.x ghetto (which is
   > pretty cozy, i must say),

   (Speaking of which, do let me know when rpx has left the ghetto,
   too. :-))

OK, will do.  If the world doesn't end, a couple more years, maybe...

   > ‘send’ gratuitously demands its MESSAGE arg (a string) be writable.
   > [...]  Here is the fix:

   Sounds great.  There are ‘sendto’ unit tests, but no ‘send’ tests.
   As a bonus, if you feel like adding a couple of these, you’re
   welcome.  :-)

I plan to add some tests, yes.

   > 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.

   > $ glog branch_release-1-8.. --reverse

   “glog”?  :-)

A small script, here in its entirety:

#!/bin/sh
exec git log --date=short --format='%h %ad %s' "$@"

   > [...]
   > 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.

   I think I once said we SHOULD release 1.8.9 RSN.  Would you
   like to take care of that?

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

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).

   > The changes are done in a hybrid ttn-gnu maintainance style.

   I’m not sure what you mean here.  :-)

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.)

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...

Other ttn-style stuff: no EOL whitespace, use SPC for indentation,
strict EOF "ends here" comment maintenance.  Where a file is not stylish
enough :-D, the MO is to do these changes opportunistically (preceding
the actual required change) in their own "nfc" commits.  This MO is
evidenced in the pushed branch.

   > 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.

-- 
Thien-Thi Nguyen ..................................... GPG key: 4C807502
.                  NB: ttn at glug dot org is not me                   .
.                 (and has not been since 2007 or so)                  .
.                        ACCEPT NO SUBSTITUTES                         .
........... please send technical questions to mailing lists ...........

Attachment: pgpex7VhGTG1L.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]