Re: v2: A proposal of a consistent set of clear rules and guidelines involving snippets, phases and patches.

[Maxime Devos <maximedevos@telenet.be>]

[-- Attachment #1.1.1: Type: text/plain, Size: 2341 bytes --]


On 09-08-2022 20:58, david larsson wrote:
> On 2022-08-05 15:59, Maxime Devos wrote:
>
> [..]
>
>>
>> 20.4.5.3 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: 
<https://issues.guix.gnu.org/49828> (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.

Greetings,
Maxime.

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]