all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Nils Gillmann <ng0@n0.is>
To: Mike Gerwitz <mtg@gnu.org>
Cc: guix-devel@gnu.org, maintainers@gnu.org
Subject: Re: gnumaint changes
Date: Fri, 13 Jul 2018 10:24:45 +0000	[thread overview]
Message-ID: <20180713102445.2xaa54ynoauaqq2p@abyayala> (raw)
In-Reply-To: <877em04dp4.fsf@gnu.org>

Mike Gerwitz transcribed 3.7K bytes:
> On Thu, Jul 12, 2018 at 17:57:01 +0200, Ludovic Courtès wrote:
> > Hello,
> >
> > Mike Gerwitz <mtg@gnu.org> skribis:
> 
> [...]
> 
> >> Do you have a couple examples of what you think would be beneficial to
> >> pull form Guix?  I'm certainly open to the idea where it makes sense;
> >> there's no sense in us duplicating effort within GNU unnecessarily.
> >
> > I realize that Guix doesn’t have all GNU packages yet so in fact there’s
> > not so much to pull from at this point.  I was suspecting blurbs are
> > likely to be more up-to-date in Guix, but that’s very subjective, I
> > don’t know if this is the case.
> 
> It seems like the blurbs in Guix may be slightly different: in Womb they
> are provided by the package author for use here:
> 
>   https://www.gnu.org/manual/blurbs.html
> 
> In Guix they may be augmented with additional information that the
> Guix package author finds useful, and may deviate from what the GNU
> package author provided.  Is that true?

Yes. And for that reason I would not like that they are picked from
Guix. The package authors should keep the autonomy to decide what's
right as a description.
In Guix we change the descriptions (blurbs) according to our needs.

> It makes sense to me, though, that Guix and that page would be in
> sync.  But if the intent is to have the blurbs be written by the package
> authors, syncing them would mean that Guix would forefit the ability to
> manage its own package descriptions.  I'm not sure if that's something
> Guix would want to do.
> 
> I'm also unaware of how many GNU package maintainers even remember that
> the blurbs page even exists.  So it's possible that such descriptions
> could be updated.  It'd be worth maintainers@ occasionally asking
> package maintainers to review our records.
> 
> >> I'm also working on automating parts of our recordkeeping: in the next
> >> few weeks, Womb will have up-to-date version information automatically
> >> pulled from info-gnu release announcements; the FTP server; and a couple
> >> websites where necessary, though I'll be manually committing it for the
> >> first few months to verify that it is all working properly.  So Guix
> >> might also be able to depend on rec/gnupackages.rec for checking for new
> >> releases as well, since unfortunately GNU doesn't mandate the use of the
> >> FTP server, or even info-gnu (so releases are all over the place).
> >
> > The (guix gnu-maintenance) modules are tools to retrieve the latest
> > version of a GNU package by traversing its ftp.gnu.org (or similar)
> > directory.  That’s something you might find useful.  Here’s an example:
> 
> Thanks---I was going to reference Guix's implementation.
> 
> But do note that many GNU packages don't make use of GNU's FTP server,
> so this doesn't work on its own as a comprehensive version check
> tool for GNU software.  But if this hasn't been a practical problem for
> Guix yet, then there's no need to change that.
> 
> -- 
> Mike Gerwitz
> Free Software Hacker+Activist | GNU Maintainer & Volunteer
> GPG: D6E9 B930 028A 6C38 F43B  2388 FEF6 3574 5E6F 6D05
> https://mikegerwitz.com

  reply	other threads:[~2018-07-13 10:24 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-27  8:23 gnumaint changes Nils Gillmann
2018-06-27 20:36 ` Ludovic Courtès
2018-06-28  4:52   ` Nils Gillmann
2018-06-28  1:40 ` Mike Gerwitz
2018-06-28  1:55   ` Mike Gerwitz
2018-07-11 14:11     ` Ludovic Courtès
2018-07-12  2:51       ` Mike Gerwitz
2018-07-12 15:57         ` Ludovic Courtès
2018-07-12 16:32           ` Mike Gerwitz
2018-07-13 10:24             ` Nils Gillmann [this message]
2018-07-13 12:01             ` 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=20180713102445.2xaa54ynoauaqq2p@abyayala \
    --to=ng0@n0.is \
    --cc=guix-devel@gnu.org \
    --cc=maintainers@gnu.org \
    --cc=mtg@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.