guix-devel
[Top][All Lists]
Advanced

[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





reply via email to

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