>> 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!