[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: |
Andreas Enge |
Subject: |
Re: v2: A proposal of a consistent set of clear rules and guidelines involving snippets, phases and patches. |
Date: |
Mon, 8 Aug 2022 23:51:07 +0200 |
Hello,
Am Fri, Aug 05, 2022 at 03:59:14PM +0200 schrieb Maxime Devos:
> Here's a v2. I've changed the structure to something close to what Julien
> proposed, it looks a lot better now to me!
thanks, it does! I still find it a bit too verbose compared to Liliana's
suggestion, which I would prefer as a starting point of the discussion.
> 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.
Do you mean "phase" here instead of "snippet"? That is what I usually do...
My practice is to use a patch when the goal is to eventually change the
source code upstream (or it is already changed upstream and we can take a
patch from their git repo, say), and a phase when one cannot expect upstream
to incorporate the changes since they are specific to Guix (like embedding
store paths, as Liliana writes, where apparently a phase is the only option
anyway).
Andreas
- Re: v2: A proposal of a consistent set of clear rules and guidelines involving snippets, phases and patches., (continued)
- [PATCH] doc: Update contribution guidelines on patches, etc., Liliana Marie Prikler, 2022/08/06
- Re: [PATCH] doc: Update contribution guidelines on patches, etc., Maxime Devos, 2022/08/09
- Re: [PATCH] doc: Update contribution guidelines on patches, etc., Liliana Marie Prikler, 2022/08/09
- Re: [PATCH] doc: Update contribution guidelines on patches, etc., Maxime Devos, 2022/08/09
- Re: [PATCH] doc: Update contribution guidelines on patches, etc., Liliana Marie Prikler, 2022/08/09
- Re: [PATCH] doc: Update contribution guidelines on patches, etc., Maxime Devos, 2022/08/09
- Re: [PATCH] doc: Update contribution guidelines on patches, etc., Liliana Marie Prikler, 2022/08/10
- Re: [PATCH] doc: Update contribution guidelines on patches, etc., Maxime Devos, 2022/08/09
[PATCH v2] doc: Update contribution guidelines on patches, etc., Liliana Marie Prikler, 2022/08/10
Re: v2: A proposal of a consistent set of clear rules and guidelines involving snippets, phases and patches.,
Andreas Enge <=
Re: v2: A proposal of a consistent set of clear rules and guidelines involving snippets, phases and patches., david larsson, 2022/08/09