guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jack Hill
Subject: Re: best practise between git-fetch vs url-fetch?
Date: Mon, 25 May 2020 22:05:38 -0400
User-agent: K-9 Mail for Android

On May 25, 2020 5:17:02 PM EDT, "Ludovic Courtès" <address@hidden> wrote:
>Hi,
>
>Jack Hill <address@hidden> skribis:
>
>> 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".
>
>Regarding the ‘archival’ checker, the manual explains what’s at stake
>and what it does:
>
>  https://guix.gnu.org/manual/en/html_node/Invoking-guix-lint.html
>
>I feel like there’s little room for improvement here.

I think you're right. We have made it this far without too much confusion, and 
I agree that the text in that section is good. Let's leave it alone.

Best,
Jack




reply via email to

[Prev in Thread] Current Thread [Next in Thread]