unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Mark H Weaver <mhw@netris.org>
To: John Darrington <john@darrington.wattle.id.au>
Cc: guix-devel@gnu.org
Subject: Re: [PATCH] gnu: Fix load-extension path in packaging of guile-ncurses.
Date: Sat, 24 Dec 2016 10:39:40 -0500	[thread overview]
Message-ID: <87mvflz683.fsf@netris.org> (raw)
In-Reply-To: <20161222082001.GA3545@jocasta.intra> (John Darrington's message of "Thu, 22 Dec 2016 09:20:02 +0100")

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?

       Mark

  reply	other threads:[~2016-12-24 15:40 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-19 17:50 (unknown), John Darrington
2016-12-19 17:50 ` [PATCH] gnu: Fix load-extension path in packaging of guile-ncurses John Darrington
2016-12-19 21:17   ` Ludovic Courtès
2016-12-20  7:17   ` Mark H Weaver
2016-12-20 11:03     ` John Darrington
2016-12-20 14:16       ` John Darrington
2016-12-21  8:36       ` Danny Milosavljevic
2016-12-21  9:56         ` John Darrington
2016-12-22  5:56           ` Tobias Geerinckx-Rice
2016-12-22  8:20             ` John Darrington
2016-12-24 15:39               ` Mark H Weaver [this message]
2016-12-24 17:02                 ` John Darrington
2017-01-16  0:11                   ` Mark H Weaver

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87mvflz683.fsf@netris.org \
    --to=mhw@netris.org \
    --cc=guix-devel@gnu.org \
    --cc=john@darrington.wattle.id.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).