all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: Andreas Enge <andreas@enge.fr>
Cc: guix-devel@gnu.org
Subject: Re: Agreeing on some "rules" for packaging.
Date: Sat, 31 Aug 2013 11:31:08 +0200	[thread overview]
Message-ID: <87d2ouxl43.fsf@gnu.org> (raw)
In-Reply-To: <20130830215908.GA28681@debian> (Andreas Enge's message of "Fri, 30 Aug 2013 23:59:08 +0200")

Andreas Enge <andreas@enge.fr> skribis:

> On Thu, Aug 29, 2013 at 12:42:31AM +0200, Ludovic Courtès wrote:

[...]

>> I would perhaps move “Python Modules” into a “Specific Packages”
>> subsection (or something like that), where we might eventually have
>> “Perl Packages” as well.  WDYT?
>
> Maybe once we have Perl Packages. I do not want to create too many sublevels.
> Or we just create a separate section Perl Packages, depending on whether we
> write essentially the same thing or not.

OK, makes sense.

>> s/But see @ref{Python Modules}/@xref{Python Modules},/
>
> No, since @xref creates text starting by "See", so is only suitable for the
> beginning of a sentence.

What I’m suggesting here is precisely to start the sentence with @xref,
as recommended (info "(texinfo) @ref"):

    The '@ref' command can tempt writers to express themselves in a manner
  that is suitable for a printed manual but looks awkward in the Info
  format. [...]

    In general, it is best to use '@ref' only when you need some word
  other than "see" to precede the reference.  When "see" (or "See") is ok,
  '@xref' and '@pxref' are preferable.


>> s/defined in @ref {Package Naming}/previously defined (@pxref{Package Naming})/
>
> This also gives strange output with an additional "see".

It yields something like:

  previously defined (see Section 4.2 “Package Naming”)

How strange is that?  :-)

>> Also, please leave two spaces after an end-of-sentence period.
>
> Okay. I suppose this also means that the period at the end of a sentence
> is not allowed to fall at the end of an input line?

No, that’s not necessary, fortunately.

> Since there have not been any objections on the content of the guidelines,
> maybe you could push Python 3 following this rule, Cyril? I am curious
> whether all our packages will survive the switch to Python 3...

Well let’s pull the trigger and see what happens.  :-)

Thanks,
Ludo’.

  reply	other threads:[~2013-08-31  9:36 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-27 21:46 Agreeing on some "rules" for packaging Cyril Roelandt
2013-08-27 22:31 ` Nikita Karetnikov
2013-08-28  6:29 ` Andreas Enge
2013-08-28 12:51 ` Ludovic Courtès
2013-08-28 18:32   ` Cyril Roelandt
2013-08-28 20:56     ` Andreas Enge
2013-08-28 22:42       ` Ludovic Courtès
2013-08-28 22:37         ` Cyril Roelandt
2013-08-29  8:59           ` Ludovic Courtès
2013-08-30 21:59         ` Andreas Enge
2013-08-31  9:31           ` Ludovic Courtès [this message]
2013-08-31 10:00             ` Andreas Enge
2013-08-31 10:22               ` Ludovic Courtès
2013-08-28 20:57     ` Ludovic Courtès
2013-08-30 18:15 ` Nikita Karetnikov
2013-08-30 19:35   ` Ludovic Courtès
2013-08-30 21:09     ` Nikita Karetnikov
2013-08-30 21:22       ` Ludovic Courtès
2013-08-30 21:49     ` Ludovic Courtès
2013-09-07  8:20 ` Nikita Karetnikov
2013-09-07  8:36   ` Andreas Enge
2013-09-07 13:11   ` Ludovic Courtès

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

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

  git send-email \
    --in-reply-to=87d2ouxl43.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=andreas@enge.fr \
    --cc=guix-devel@gnu.org \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.