Re: [PATCH] gnu: Fix load-extension path in packaging of guile-ncurses.

[Mark H Weaver <mhw@netris.org>]

John Darrington <john@darrington.wattle.id.au> writes:

> On Sat, Dec 24, 2016 at 10:39:40AM -0500, Mark H Weaver wrote:
>      John Darrington <john@darrington.wattle.id.au> writes:
>      
>      > We can argue about this till we're blue in the face.
>      >
>      > But on a pragmatic level, Mark's question demonstrates perfectly
>      > that our current system is lacking.
>      
>      No it doesn't.  Our convention, taken from the GNU coding standards, is
>      that the rationale for non-obvious code belongs in the code itself.  My
>      question demonstrates perfectly that you should have done _that_.
>      
>      For what it's worth, I agree that there are some cases where adding
>      rationale comments to the code itself doesn't make sense (e.g. when
>      removing code), but this is clearly not one of those cases.
>      
>      >      > Having it in the commit message would certainly have avoided me 
>      >      > having to explain the situation to Mark too.
>      >      
>      >      Perhaps. I doubt it. I can't speak for Mark, but most confusion
>      >      seemed to stem from the commit message's accuracy, not its length.
>      
>      Yes, exactly.
>      
>      To be honest, I find it unsettling that after all that has been pointed
>      out in this thread, you still seem unwilling to admit that you made any
>      mistake here.
>      
>      Have you looked at the build log, and specifically the part of the build
>      log that corresponds to your 'fix-libguile-ncurses-file-name' phase?
>      
>      Have you noticed how the 'build' and 'install' phases consist mostly of
>      commands that were already run in your custom phase?
>      
>      Do you still think that "Install shared object before attempting to
>      build the package" is an accurate statement?
>      
> I offered to change this comment.  You have ignored my offer.

It's impossible to change that comment, because it's in the commit log.
That's yet another reason why the source code itself is a better place
for documentation than the commit logs.

      Mark