[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: On commit access, patch review, and remaining healthy
From: |
Paul Jewell |
Subject: |
Re: On commit access, patch review, and remaining healthy |
Date: |
Sun, 19 Jun 2022 08:55:36 +0200 |
> On 15 Jun 2022, at 09:15, Arun Isaac <arunisaac@systemreboot.net> wrote:
>
> I would also like to raise a couple of more controversial suggestions:
>
> Should we restrict the set of packages that will be accepted into Guix?
> Currently, we accept practically any free software package into
> Guix. Should we limit the number of packages we will accept in order to
> ease maintenance? "Minimal" distros like Arch Linux do this, for
> example.
>
> The cons are that, say if we reject packages involving difficult
> languages (think javascript), we may alienate a section of our users
> (and potential users) and thus inhibit further growth. If we go down
> this route, Guix may never grow into an "universal distribution" like
> Debian is.
>
If there is someone willing to maintain the packages, then in my opinion such
restrictions shouldn’t be applied. I guess this would mean knowing who is the
maintainer for each package in guix, but this could also be a team (reference
the recent teams discussion).
> Also, should we remove old/broken/unused/rarely-used packages from Guix?
> In the past, I have packaged and contributed very niche packages which
> probably no one else uses, and sometimes even I don't use anymore. But,
> these packages continue to stay in Guix and add to the maintenance
> burden. Should we have some policy to phase out such packages,
> especially if such packages break often? I mean, that there is no need
> to phase out an elisp package that builds trivially all the time, but
> what about more complex packages that take many many hours to maintain?
I think they should be removed. This could link to the maintainer comment
above. If a package is identified as old or broken, then users could be
notified, and after a “cooling off” period they are removed. This could allow
for discussion about whether removal is appropriate, or whether someone else
would step up and update the package. Under Gentoo (the distro I know well,
having used it since 2004), obsolete and problematic packages are hard masked,
and users notified why, and when removal from the repository will occur. The
hard masking prevents new installations (almost - you can make some additional
configuration changes to enable installation). Users then have a choice -
support the resolution of the issues leading to hard masking, or move the
package definition to a personal repository so it can continue to be used (at
their own risk). Regarding rarely used packages - I wouldn’t remove these if
there is a maintainer for them and they are still being kept up to date. If
this no longer happens, then they are in the old/broken category.
I guess the big question for me is “could this be automated in some way?”
> I don't have strong opinions on these questions. I would love to hear
> what others think.
>
I hope my comments are useful!
Best regards,
Paul
- Re: On commit access, patch review, and remaining healthy, (continued)
- Re: On commit access, patch review, and remaining healthy, Luis Felipe, 2022/06/02
- Re: On commit access, patch review, and remaining healthy, Arun Isaac, 2022/06/06
- Re: On commit access, patch review, and remaining healthy, Ludovic Courtès, 2022/06/06
- Re: On commit access, patch review, and remaining healthy, zimoun, 2022/06/07
- Re: On commit access, patch review, and remaining healthy, Giovanni Biscuolo, 2022/06/08
- Re: On commit access, patch review, and remaining healthy, zimoun, 2022/06/14
- Re: On commit access, patch review, and remaining healthy, Arun Isaac, 2022/06/15
- Re: On commit access, patch review, and remaining healthy, Ludovic Courtès, 2022/06/15
- Re: On commit access, patch review, and remaining healthy,
Paul Jewell <=
- Re: On commit access, patch review, and remaining healthy, Arun Isaac, 2022/06/20
- Re: On commit access, patch review, and remaining healthy, Giovanni Biscuolo, 2022/06/15
- Re: On commit access, patch review, and remaining healthy, Giovanni Biscuolo, 2022/06/08
- Re: On commit access, patch review, and remaining healthy, Arun Isaac, 2022/06/09
Re: On commit access, patch review, and remaining healthy, Giovanni Biscuolo, 2022/06/08
- Re: On commit access, patch review, and remaining healthy, Arun Isaac, 2022/06/09
- Re: On commit access, patch review, and remaining healthy, Giovanni Biscuolo, 2022/06/10
- Re: On commit access, patch review, and remaining healthy, Maxime Devos, 2022/06/10
- Re: On commit access, patch review, and remaining healthy, Efraim Flashner, 2022/06/10
- Re: On commit access, patch review, and remaining healthy, Giovanni Biscuolo, 2022/06/10