all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Greg Hogan <code@greghogan.com>
To: "Noé Lopez" <noe@xn--no-cja.eu>
Cc: guix-devel@gnu.org
Subject: Re: Discussion on Guix funding // future
Date: Fri, 25 Oct 2024 17:26:38 -0400	[thread overview]
Message-ID: <CA+3U0Z=VKCL3mhVNbXLz16QdxY8sHvq5C_-bi=HV5R33u6uFUw@mail.gmail.com> (raw)
In-Reply-To: <87wmhwz2iz.fsf@xn--no-cja.eu>

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


  reply	other threads:[~2024-10-25 21:27 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-25 14:21 Discussion on Guix funding // future Noé Lopez via Development of GNU Guix and the GNU System distribution.
2024-10-25 21:26 ` Greg Hogan [this message]
2024-10-26 14:43   ` Forge and build automation Ludovic Courtès
2024-10-26 16:51     ` Suhail Singh
2024-10-26 22:12       ` Ludovic Courtès
  -- strict thread matches above, loose matches on Subject: below --
2024-10-24 22:08 Discussion on Guix funding // future Ekaitz Zarraga
2024-10-25  8:12 ` Steve George
2024-10-25  9:11   ` Ricardo Wurmus
2024-10-25  9:16     ` Ekaitz Zarraga
2024-10-25  9:37       ` Ricardo Wurmus
2024-10-25 11:05         ` indieterminacy
2024-10-25 11:22           ` Steve George
2024-10-25 11:51             ` indieterminacy
2024-10-25 12:05         ` Efraim Flashner
2024-10-26 17:16         ` Tomas Volf
2024-10-25 11:06     ` Steve George
2024-10-25 12:13       ` Ricardo Wurmus
2024-10-25 12:18     ` Efraim Flashner
2024-10-25 15:49       ` Steve George
2024-10-25 12:58 ` Thompson, David
2024-10-25 14:31   ` Christopher Howard
2024-10-26  6:57     ` Steve George
2024-10-28 16:47       ` Christopher Howard
2024-10-25 19:13   ` Ekaitz Zarraga
2024-10-25 23:25     ` Attila Lendvai
2024-10-26 12:49       ` Greg Hogan
2024-10-28  9:21   ` Andreas Enge
2024-10-26 15:04 ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CA+3U0Z=VKCL3mhVNbXLz16QdxY8sHvq5C_-bi=HV5R33u6uFUw@mail.gmail.com' \
    --to=code@greghogan.com \
    --cc=guix-devel@gnu.org \
    --cc=noe@xn--no-cja.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.