[Top][All Lists]

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

Re: 1.8 ‘send’ bug + re-engagement

From: Ludovic Courtès
Subject: Re: 1.8 ‘send’ bug + re-engagement
Date: Mon, 24 Sep 2012 22:27:45 +0200
User-agent: Gnus/5.130005 (Ma Gnus v0.5) Emacs/24.2 (gnu/linux)


Thanks for the update!

Thien-Thi Nguyen <address@hidden> 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 <address@hidden>
  Date:   Wed Aug 22 14:51:33 2012 +0200

      Rename to, twice


  commit 04d7f4a80fb84a7333bb58c831591a59f42ab59b
  Author: Thien-Thi Nguyen <address@hidden>
  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 <address@hidden>
  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 <address@hidden>
  Date:   Thu Aug 23 17:43:47 2012 +0200

      configure: Dose w/ "proper" m4-quoting

OK, but must also be adjusted & applied to other branches.

  commit 037b7f6a16d06073ae2b1f5cd3ad2588b2685455
  Author: Thien-Thi Nguyen <address@hidden>
  Date:   Wed Aug 22 18:16:23 2012 +0200

      configure, int: Remove EOF "Local Variables" block; nfc


  commit b3ee8403f89b21b1f9bda7fa93ef43861726fe5e
  Author: Thien-Thi Nguyen <address@hidden>
  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 <address@hidden>
  Date:   Thu Aug 23 18:09:17 2012 +0200

      Delete EOL whitespace; nfc

As above.

  commit 60a29ffea0b596ae19b3a5bafbcc47bfec50b3b9
  Author: Thien-Thi Nguyen <address@hidden>
  Date:   Thu Aug 23 18:17:08 2012 +0200

      libguile: Fix bug: Don't expect 'send' string to be writable


  commit d70f9c8869aa46898e52124c4e42d0d0059210d7
  Author: Thien-Thi Nguyen <address@hidden>
  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


> 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 / / doc-mangling).


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


> 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

IOW: I find it important to maintain 1.8, but not at the cost of
reducing hack power on 2.0/2.1.


reply via email to

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