unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Jack Hill <jackhill@jackhill.us>
To: Tobias Geerinckx-Rice <me@tobias.gr>
Cc: guix-devel@gnu.org, Brice Waegeneire <brice@waegenei.re>
Subject: Re: best practise between git-fetch vs url-fetch?
Date: Thu, 14 May 2020 12:16:29 -0400 (EDT)	[thread overview]
Message-ID: <alpine.DEB.2.20.2005141149400.5735@marsh.hcoop.net> (raw)
In-Reply-To: <878shv3dzz.fsf@nckx>

[-- Attachment #1: Type: text/plain, Size: 1837 bytes --]

On Wed, 13 May 2020, Tobias Geerinckx-Rice wrote:

>> --with-commit
>
> Yes, this is niice.  ♥
>
> For the sake of argument¹, though, so is --with-source=<actually released and 
> supported upstream tarball dot tar>.
>
> Somehow erasing that hard distinction is the real winning move.
>
> Kind regards,
>
> T G-R
>
> [1]: Obligatory <https://xkcd.com/1432>.

Heh, I'll take the bait. I also really appreciate how easy we make it for 
people to exercise their software freedom and run modified software. How 
best to make that possible and balance it with other usability constraints 
(e.g. mirror:// urls should be more robust) may vary by package, so I 
agree with Leo that some discretion is needed. However, that's not to say 
that I wouldn't appreciate some guidance as to our default preference when 
there is no package-specific reason to prefer one way over the other.

It seems a bigger problem is when the build method for the git repository 
and release tarball are different. In many packages this is because of the 
pre-generated autotools build system in the release tarballs. Should we 
bootstrap the autotools build system even when building from a release 
tarball? As I understand it, autotools has historically been treated this 
way in part to allow building on systems without the right version of 
autotools, but is that really a problem in Guix? Why should it be treated 
differently than other pre-generated artifacts which we rebuild?

Another improvement we could make here is improving the message about 
Software Heritage in guix lint. Most of the other messages it emits are 
things that the author of a package should consider improving. If the 
Software Heritage message is less actionable, let's make that clearer so 
that people don't think there is a problem with their package definition.

Best,
Jack

  reply	other threads:[~2020-05-14 16:16 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20200306091524.5044.11103@vcs0.savannah.gnu.org>
     [not found] ` <20200306091525.E8A1621163@vcs0.savannah.gnu.org>
2020-03-06 14:37   ` 01/02: gnu: fmt: Use HTTPS and git-fetch Marius Bakke
2020-03-06 15:07     ` Pierre Neidhardt
2020-03-06 17:40       ` Marius Bakke
2020-03-07  7:46         ` Pierre Neidhardt
2020-03-07 11:37           ` Pierre Neidhardt
2020-03-11 14:39         ` Ludovic Courtès
2020-03-11 14:54           ` Pierre Neidhardt
2020-05-13  1:08             ` best practise between git-fetch vs url-fetch? zimoun
2020-05-13  8:24               ` Brice Waegeneire
2020-05-13 18:07                 ` Tobias Geerinckx-Rice
2020-05-14 16:16                   ` Jack Hill [this message]
2020-05-24 20:04                     ` Josh Marshall
2020-05-24 20:30                     ` Ludovic Courtès
2020-05-25  4:54                       ` Jack Hill
2020-05-25 21:17                         ` Ludovic Courtès
2020-05-26  2:05                           ` Jack Hill
2020-05-13 17:13               ` Leo Famulari
2020-05-24 20:34                 ` Ludovic Courtès
2020-05-26 11:41               ` zimoun

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=alpine.DEB.2.20.2005141149400.5735@marsh.hcoop.net \
    --to=jackhill@jackhill.us \
    --cc=brice@waegenei.re \
    --cc=guix-devel@gnu.org \
    --cc=me@tobias.gr \
    /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).