Hi Andreas, On Sun, 22 Jan 2023 at 18:18, Andreas Enge <andr...@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....@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....@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....@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-patc...@gnu.org 4: <https://guix.gnu.org/manual/devel/en/guix.html#Submitting-Patches> Cheers, simon