[Top][All Lists]

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

Re: v2: A proposal of a consistent set of clear rules and guidelines inv

From: Maxime Devos
Subject: Re: v2: A proposal of a consistent set of clear rules and guidelines involving snippets, phases and patches.
Date: Tue, 9 Aug 2022 22:53:36 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0

On 09-08-2022 20:58, david larsson wrote:
On 2022-08-05 15:59, Maxime Devos wrote:

[..] Fixing technical issues (compilation errors, test failures,
other bugs ...)

Usually, a bug fix comes in the form of a patch copied from upstream
or another distribution. In that case, simply adding the patch to the
'patches' field is the most convenient and usually does not cause any
problems; there is no need to rewrite it as a snippet or a phase.

If no ready-made patch already exists, then choosing between a patch
or a snippet is a matter of convenience. However, there are two things
to keep in mind:

First, when the fix is not Guix-specific, it is strongly desired to
upstream the fix to avoid the additional maintenance cost to Guix. As
upstreams cannot accept a snippet, writing a patch can be a more
efficient use of time. Secondly, if the fix of a technical issue
embeds a store file name, then it has to be a phase. Otherwise, if a
store file name was embedded in the source, the result of 'guix build
--source' would be unusable on non-Guix systems and likely also
unusable on Guix systems of another architecture.

There may be other reasons to add patches: [...]

Agreed (*), but I don't think that subsection claims those are the only reasons for patches -- that section is only about fixing technical issues, not adding new features, as implied by the name of the section.

I can look at adding a new subsection 'Adding new functionality' for a v3.

Liliana's documentation contains some information not in my v2, I intend to look into integrating that information as well.

1. Functionality, that is not yet accepted upstream, because maintainer(s) do not have enough time to review all pull requests, or are simply slow to review. "if no response within X time from upstream, then guix may include your patch" might be a good policy here.

(*) We sometimes do such things already. Example: <> (nowadays upstreamed). I don't think this thread is a good place for deciding on the exact rules though -- deciding on an appropriate value of X seems difficult, I would like to separate that from the current documentation patch.


Attachment: OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

reply via email to

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