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

[Arun Isaac <arunisaac@systemreboot.net>]

>> 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 like this idea. We already have a way to mark packages as
deprecated. The Gentoo method seems like a way to mark packages that are
"about to be deprecated". I like the way it notifies the user of the
impending deprecation without the user having to subscribe to the
mailing list or the issue tracker.

> I guess the big question for me is “could this be automated in some
> way?”

Indeed, it's all a matter of somebody implementing the tooling! ;-) Like
Ludo mentioned, Cuirass and the Guix data service may be involved in
determining which packages are frequently broken.

>> I don't have strong opinions on these questions. I would love to hear
>> what others think.
>> 
>
> I hope my comments are useful!

Definitely, thanks!