Re: Discussion on Guix funding // future

Re: Discussion on Guix funding // future

[Noé Lopez via Development of GNU Guix and the GNU System distribution.]

Hey everyone,

As a relatively new user and contributor I thought I should share my
point of view.

When I started using Guix, the documentation was the greatest thing
ever, few projects have a manual like this that can help you in so many
situations.  Of course the lack of wifi drivers was an issue, and I
wished it had a mention that solutions exist, even if not endorsing
them.

This, in my opinion, should be improved as it turns Guix into a hostile
project towards users that *need* these non-free drivers to make it
work, as bad as it is.  What I mean by hostile is you will see on the
internet people saying don’t even dare trying to talk about it on the
list.  Or the nonguix project having to mention to not ask for help
about itself.  Trying to silence people in this way is a real shame and
we can’t just act like non-free drivers don’t exist and people don’t
need them.

This leads me to my next point, which is there’s no reference to
external resources from the guix websites/manual.  Things like the
toys.whereis channel webring, system crafters, the lemmy community, the
many channels like rde, guix-science, or even nonguix.  These are
important parts of the ecosystem and should not be left out as they are,
we should acknowledge them and reference them.

Furthermore, on the topic of mail, I totally agree with David
Thompson. Mail is cool, I get it, but another way to contribute like
pull requests on a forgejo/gitlab mirror would be much, much easier.
Mail might seem like the default easy thing for many of you, but for
anyone that’s a new contributor needing to configure send-mail and
making sure that your email was received and that you receive the
replies, not seeing it appear on the issues list for a little while is
quite inconvenient compared to using git, pushing on your fork and
continuing with a web interface from there.

Overall, Guix is a great project but it should take care of opening
itself to keep up with the times.

– Noé

Re: Discussion on Guix funding // future

[Greg Hogan]

On Fri, Oct 25, 2024 at 10:21 AM Noé Lopez via Development of GNU Guix
and the GNU System distribution. <guix-devel@gnu.org> wrote:
>
> Furthermore, on the topic of mail, I totally agree with David
> Thompson. Mail is cool, I get it, but another way to contribute like
> pull requests on a forgejo/gitlab mirror would be much, much easier.
> Mail might seem like the default easy thing for many of you, but for
> anyone that’s a new contributor needing to configure send-mail and
> making sure that your email was received and that you receive the
> replies, not seeing it appear on the issues list for a little while is
> quite inconvenient compared to using git, pushing on your fork and
> continuing with a web interface from there.

Can the suggested, user-friendly alternatives to email integrate into
the build cluster, QA, and teams-branches workflow?

WIth 29,000+ packages the nature of the project has changed from
adding new software to managing updates (what fraction of new packages
are rust or python dependencies?).

What we have works well but Guix needs even more tooling and
automation! We have importers and updaters. There exist innumerable
free software updates, of which Guix only applies a pseudorandom few.
Much of this could be automated using the existing tooling for
updating package versions and building dependents. We can automate
multi-versioning ('pinning') libraries for upgrade failures.

Guix should be capable of things like keeping git up-to-date, but this
isn't scaling. #73309 was submitted two weeks ago. #70656, submitted
by a core contributor six months ago, reduces the git dependents from
921 to 136 and appears overlooked. We need more of the latter
submissions in order to better automate the former (#70031 does this
for cmake). As noted recently, "upgrading Numpy and friends" is
challenging. How can that process be improved?

If our goal is "how can I keep package X up-to-date" rather than "can
I update package X", it isn't clear to me that moving to forgejo or
gitlab takea Guix in that direction.

Greg

Forge and build automation

[Ludovic Courtès]

Hello!

(“As an online Guix discussion grows longer, the probability of ending
up talking about the email workflow approaches 1.”)

Greg Hogan <code@greghogan.com> skribis:

> On Fri, Oct 25, 2024 at 10:21 AM Noé Lopez via Development of GNU Guix
> and the GNU System distribution. <guix-devel@gnu.org> wrote:
>>
>> Furthermore, on the topic of mail, I totally agree with David
>> Thompson. Mail is cool, I get it, but another way to contribute like
>> pull requests on a forgejo/gitlab mirror would be much, much easier.
>> Mail might seem like the default easy thing for many of you, but for
>> anyone that’s a new contributor needing to configure send-mail and
>> making sure that your email was received and that you receive the
>> replies, not seeing it appear on the issues list for a little while is
>> quite inconvenient compared to using git, pushing on your fork and
>> continuing with a web interface from there.
>
> Can the suggested, user-friendly alternatives to email integrate into
> the build cluster, QA, and teams-branches workflow?

At work, we have integrated Cuirass (guix.bordeaux.inria.fr) with GitLab
(gitlab.inria.fr) for the purposes of testing merge requests for our
channels.  It’s wonderful, really.

As someone who’s often repelled by web interfaces, I have also
experimented with forge.el, an Emacs interface to Git{Hub,Lab}, Forgejo,
and more; it is “promising”.

But…

> WIth 29,000+ packages the nature of the project has changed from
> adding new software to managing updates (what fraction of new packages
> are rust or python dependencies?).

… that’s the crux of the problem.  What works for our little channels
mentioned above is insufficient for the main ‘guix’ channel.

qa.guix is a very adequate tool.  Should we decide to experiment with
something like Forgejo, we would need to make sure its webhooks can be
understood by qa.guix.

Surely not insurmountable, and worth considering.  We “just” need more
hands to try that out.


Besides, I agree with you Greg that we need more automation, in
particular for package updates.  Nixpkgs has an auto-update bot; we
could just as well have a bot that roughly runs ‘guix refresh’ and
submits patches/merge requests.  I’m sure somebody will end up
scratching this particular itch, it’s such an obvious thing to do.

Thanks,
Ludo’.

PS: It’s a long thread and I do mean to comment on other issues, but
    it’s going to take me a while.  :-)

Re: Forge and build automation

[Suhail Singh]

Ludovic Courtès <ludo@gnu.org> writes:

>> WIth 29,000+ packages the nature of the project has changed from
>> adding new software to managing updates (what fraction of new packages
>> are rust or python dependencies?).
>
> … that’s the crux of the problem.  What works for our little channels
> mentioned above is insufficient for the main ‘guix’ channel.

Why does the main 'guix' channel have to contain the "entire world"?

> Besides, I agree with you Greg that we need more automation, in
> particular for package updates.  Nixpkgs has an auto-update bot; we
> could just as well have a bot that roughly runs ‘guix refresh’ and
> submits patches/merge requests.  I’m sure somebody will end up
> scratching this particular itch, it’s such an obvious thing to do.

Where would such a bot run?  Do we have an example of a bot that runs in
a similar context?

-- 
Suhail

Re: Forge and build automation

[Ludovic Courtès]

Suhail Singh <suhailsingh247@gmail.com> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:

[...]

>> Besides, I agree with you Greg that we need more automation, in
>> particular for package updates.  Nixpkgs has an auto-update bot; we
>> could just as well have a bot that roughly runs ‘guix refresh’ and
>> submits patches/merge requests.  I’m sure somebody will end up
>> scratching this particular itch, it’s such an obvious thing to do.
>
> Where would such a bot run?  Do we have an example of a bot that runs in
> a similar context?

Yes, there’s a bot periodically updating the guix-cran and guix-bioc
channels:

  https://hpc.guix.info/channel/guix-cran
  https://hpc.guix.info/channel/guix-bioc

Currently it’s a script running periodically on berlin.guix:

  https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/modules/sysadmin/services.scm#n1335

Ludo’.

Re: Forge and build automation

[Simon Tournier]

Hi,

On Sat, 26 Oct 2024 at 16:43, Ludovic Courtès <ludo@gnu.org> wrote:

> (“As an online Guix discussion grows longer, the probability of ending
> up talking about the email workflow approaches 1.”)

My comment to make it 1. ;-)


> As someone who’s often repelled by web interfaces, I have also
> experimented with forge.el, an Emacs interface to Git{Hub,Lab}, Forgejo,
> and more; it is “promising”.
>
> But…

…Two very important features for me are still lacking:

 1. Somehow, Web-interface forges are against user autonomy principle.

    In order to allow user autonomy, web-interface forges must work on
    standard API and standard protocol.  Without standard, it’s a dead
    end.  It’s not sustainable to work on some clients.  How many years
    of Git{Hub,Lab}?  How many clients?

 2. It’s hard to deal with the tracker without being online.

    As far I have tried, I need to be online for interacting and so I
    cannot batch: fetch some issues, process them offline, push my
    comments at once.


All that said, such discussion about “email workflow” makes me think it
underlines an important point about Guix: it appears so easy to patch
that the only focus remains on the patch submission.  That’s a good
thing! :-)


Cheers,
simon