Re: Proposed changes to the commit policy (#59513)

[Simon Tournier]

Hi Andreas,

On Sun, 22 Jan 2023 at 18:18, Andreas Enge <andreas@enge.fr> wrote:

> So I tried it once, and find the hassle offputting. It feels like doubling
> the effort - after doing the real work, I need to get back to it a week
> later and more or less go through the motions again (rebase the commit
> and resign it, recompile Guix, build the package again just in case),
> plus the debbugs effort.

As mentioned here [1], it was possible to see the result of the QA for
this patch here:

    https://qa.guix.gnu.org/issue/60931

where the patch has been built on several architectures and all the
dependants too.  Now, because the patch had been pushed, this result is
not visible anymore. :-)

1: <http://issues.guix.gnu.org/msgid/864jsi1rkg.fsf@gmail.com>


That’s said, the patch had been built for all architectures and all the
dependants too, “guix lint” is applied systematically, etc.

For example, “guix lint” currently allows to be sure that the package is
archived in Software Heritage; maybe this will change in the future.

For what it is worth, I barely build for all the architectures the
patches I submit.  And I do not systematically rebuild all the
dependants because sometimes I “feel confident” it is a “trivial” change
that does not deserve such rebuild.  For sure, I do not remember rebuild
all the dependants for all the architectures.


Well, between the lines, are you suggesting that it is broken by design? :-)

Other said, it would not be possible to have the dashboard [2] all
green, right?  Because the QA provides some green lights for a state but
then you push to another state where the lights are unknown.

2: <http://ci.guix.gnu.org/eval/134159/dashboard>


> So expect even less package updates from my part in the future... These
> were the kind of instant gratification actions one could do more or less
> in the background, and they have become more complex administrative
> endeavours with delayed gratification.

While I understand this “extra“ work is a burden, what would you suggest
to reduce the number of broken packages?  Because all the red circles in
the dashboard [2] is a strong issue, IMHO.

When using Debian, I cross the fingers each time I run ‘apt upgrade’.
Using Guix, I cross the fingers each time I run ‘guix pull’.  Surprise,
surprise. :-)  Sometimes, the package that worked still works, sometimes
not.

This kind of example [3]:

        Well, for a concrete example, please give a look at [0].  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’.

        0: <http://issues.guix.gnu.org/msgid/86wn7kd0m9.fsf@gmail.com>

happens more than often.  Give a look at the dashboard. ;-) Obviously,
no blame. :-) Moreover, the complexity of all the parameters is not
tractable only by manual actions, IMHO.

At work, the feedback I often get is: Guix is not enough stable to daily
work and users cannot spend time to investigate if they are doing
something wrong or if it is broken.  People are fix again and again
something unrelated to their current task just because they did “guix
pull” (for having some new packages, some security fixes, etc.).

To avoid misunderstanding, I daily work with Guix and I am happy. :-)

Well, as I also wrote earlier [3]. :-) « We – from core developers to
user just wanting the things done – are all pulling the same branch.
This branch cannot satisfy in the same time all the constraints; is the
current push/pull branch model satisfying the best optimum with the
resource and tools at hand? »

Maybe the current full rolling-release applied to functional package
management does not scale well?

3: <https://yhetil.org/guix/86tu8xdlbw.fsf@gmail.com>


> Am Wed, Jan 18, 2023 at 04:54:58PM +0000 schrieb Kaelyn:
>> On a side note, I'd recently discovered the flag to pass. To have a
>>subject prefix like "[PATCH core-updates]" (as mentioned in the manual
>>for staging and core-updates patches) instead of the default "[PATCH]",
>>one can pass "--subject-prefix="PATCH core-updates" to git
>>format-patch. 
>
> This sounds like it could be a useful addition to the QA process.

To my knowledge, it is not possible to continuously build core-updates
because the project does not have enough resource (both human power and
machine power).

Or do you mean mentioning this option of git-format-patch under point #9
of «Submitting Patches» [4]?  Because this option is already in the
manual under «Sending a Patch Series» section:

     Tip: To add a prefix to the subject of your patch, you may use the
     ‘--subject-prefix’ option.  The Guix project uses this to specify
     that the patch is intended for a branch or repository other than
     the ‘master’ branch of
     <https://git.savannah.gnu.org/cgit/guix.git>.

          git send-email -1 -a --base=auto \
              --subject-prefix='PATCH core-updates' \
              --to=guix-patches@gnu.org

4: <https://guix.gnu.org/manual/devel/en/guix.html#Submitting-Patches>


Cheers,
simon