Hi Ludo´,
Firstly, you're side-stepping the main point of this thread, that it
will be difficult to amend the GCD.
We are pushing for much stricter commitments than necessary to achieve
our goals. That is fine as a temporary setup, because yes, currently
there are legal/ethical/moral/environmental concerns. But those will be
resolved and consensus will subsequently shift (in either direction).
But the asymmetry of the GCD process will mean that it will be very
difficult to update our policy accordingly. I fear we are painting
ourselves in a corner.
The part about better tooling was only an example about why we don't
have the luxury to permit ourselves a commitment that goes much further
than strictly necessary.
I did not intent to have a whole discussion about the tooling, but well,
it is interesting.
On 8/7/26 22:18, Ludovic Courtès wrote:
Hugo Buddelmeijer <[email protected]> skribis:
Secondly, it seems all packages have an explicit set of
maintainers. For example their onnx has two maintainers, and those
maintainers are only maintainer of a handful of packages each.
Adding a new package to Nix requires you to either become a maintainer
yourself, or find someone who is willing to adopt the package.
This is a model we rejected early on in Guix (see commit
154f1f0937754fafac0c6288dd458b66b332e6bb) in favor of collaborative
maintenance, now incarnated as teams.
I don't know where to find that commit, it seems not to be in Guix,
could you please give me a pointer?
I'm fine with doing things in a different way than Nix; I only looked at
how they do things because you suggested taking inspiration from them.
A strength I can see in our collaborative approach is that it forces
knowledge sharing, and prevents silos from forming, potentially making
us more resilient.
But we should do better with the knowledge sharing; my first reaction
when I `guix edit broken-package` is often "why are all these unusual
things here?". The comments often only explain 'what', not 'why'.
I won’t claim this is perfect but the choice was motivated by different
group dynamics and informed by the experience of Debian.
But I feel we are taking this too lightly. People will want to have
some time left to actually use the packages :-).
Many people have been working hard, be it on tooling or on the actual
update work; those people certainly don’t take it too lightly.
Both can be true at the same time. That only highlights my appreciation
for the people already working on the package maintenance tooling.
Did someone ever make a plot to see how out-of-date our packages are
over time? Might be interesting to see whether we are on the right
track.
https://repology.org/repository/gnuguix
Thanks. I'm hoping for something that shows how far the packages are
outdated; whether that gap grows or shrinks.
Because if the gap shrinks, then we can continue on our current path,
but if the gap grows, then we need to change something. I'll try to
create something.
And tying this to the GCD: we should do such an analysis before
committing to refrain from alternative approaches.
Hugo
