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

[Maxime Devos]

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.

OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key

OpenPGP_signature
Description: OpenPGP digital signature