Re: best practise between git-fetch vs url-fetch?

[Jack Hill <jackhill@jackhill.us>]

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

On Sun, 24 May 2020, Ludovic Courtès wrote:

[…]

>> 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.
>
> What message would you suggest?

How about expanding section 7.7 "Invoking Guix Lint" in the manual to 
include a paragraph of advice in the explanation for each checker. For 
example, the advice could be could be "change the source to use git-fetch" 
for "source-unstable-tarball", "exercise judgment on the long-term 
availability of software sources. We think that code hosted on the GNU ftp 
servers will be around for a long time, but code on people's personal 
websites may not be. The greater the risk of the software disappearing, 
the more important is is to use git-fetch in sources so we can trigger 
archiving at Software Heritage" for "archival", and "double check whether 
these inputs really should be native [link to appropriate section of the 
manual]. If they really need to be, leave a comment in the code briefly 
explaining why to help future contributors" for "inputs-should-be-native".

Obviously, those aren't fit to be included in the manual as is, but 
hopefully they give a good idea of what I was thinking. guix lint could 
remind people to check the manual for advice when it detects lint.

That said, I am open to other options, including that this isn't a problem 
that we need to solve.

Best,
Jack