Re: On commit access, patch review, and remaining healthy

[Paul Jewell]

> 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