[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposed changes to the commit policy (#59513)
From: |
Simon Tournier |
Subject: |
Re: Proposed changes to the commit policy (#59513) |
Date: |
Fri, 20 Jan 2023 12:50:29 +0100 |
Hi Andreas,
On mer., 18 janv. 2023 at 12:23, Andreas Enge <andreas@enge.fr> wrote:
> as a quick concrete question: Do simple package updates still count as
> trivial, or do they need to go through the patches mailing list?
> I intended to update pari-gp from 2.15.1 to 2.15.2, as usual by checking
> that all dependent packages still compile. Having to fiddle with debbugs
> is somewhat deterring (although admittedly having qa compile all dependent
> packages is also a service in a context where I do not expect problems).
In addition to Chris words. :-)
>From my point of view, the first question is if the package is a leaf or
not. :-)
Well, the main point, IMHO, of the policy (suggesting to go via
guix-patches) is to have an overview provided by qa.guix.gnu.org about
the status of all the dependents.
Being able to find all the dependents can be tricky; ’guix refresh -l’
is not always accurate because it misses some inheritance. Consider the
case:
The package B is dependent of the package A.
The package C inherits from the package B.
Then, “guix refresh -l A“ will list only B and not C. Although, a
change in the package A implies the rebuild of the package C.
Well, for a concrete example, please give a look at [1]. A “trivial”
and apparently inoffensive update of the package ’git’ from 2.38.0 to
2.38.1 breaks some Julia packages. And, “guix refresh -l git” does not
mention these Julia packages. The package ’git-minimal’ inherits from
’git’ and some Julia packages depends on ’git-minimal’.
1: <http://issues.guix.gnu.org/msgid/86wn7kd0m9.fsf@gmail.com>
All in all, going via guix-patches and let the build farm builds and
reports is a good way for avoiding potential breakages.
> but how is this specified in the email to the patch tracker,
> so that qa applies the patch to the correct branch?
I do not think the project has the resources to continuously build
core-updates. That’s one of the points with core-updates: the
collateral effects of some patches in core-updates are only know “later“
– roughly speaking when it is decided to merge core-updates; I mean, the
current state of core-updates is highly variable and depends on many
factors (the type of patches, the number of people taking care of that
branch, etc.).
Cheers,
simon
- Re: Proposed changes to the commit policy (#59513), (continued)
- Re: Proposed changes to the commit policy (#59513), Andreas Enge, 2023/01/18
- Re: Proposed changes to the commit policy (#59513), Christopher Baines, 2023/01/18
- Re: Proposed changes to the commit policy (#59513), Kaelyn, 2023/01/18
- Re: Proposed changes to the commit policy (#59513), Andreas Enge, 2023/01/22
- Re: Proposed changes to the commit policy (#59513), Simon Tournier, 2023/01/23
- Re: Proposed changes to the commit policy (#59513), Attila Lendvai, 2023/01/24
- Re: Proposed changes to the commit policy, Andreas Enge, 2023/01/25
- Re: Proposed changes to the commit policy, Ludovic Courtès, 2023/01/30
- Re: Proposed changes to the commit policy (#59513), Christopher Baines, 2023/01/30
- Re: Proposed changes to the commit policy (#59513), Simon Tournier, 2023/01/31
Re: Proposed changes to the commit policy (#59513),
Simon Tournier <=