Hi, On dim., 26 févr. 2023 at 20:11, Sharlatan Hellseher <sharlata...@gmail.com> wrote:
> Other example > > <https://git.savannah.gnu.org/cgit/guix.git/commit/?id=ba17b160ed7d09ef58183c22b6f1b10ee7ba926d> > the reason it's not updated at <http://www.catb.org/~esr/> - > development was moved to <https://gitlab.com/esr/reposurgeon>. I proposed to remove the package because it was broken and no one was willing to fix it. What is the point to keep broken packages? Here, the timeline: Report broken: 4 Dec 2018 (4 years, 12 weeks, 1 day ago) Try update: 13 Jul 2022 (32 weeks, 5 days, 20 hours ago) Propose removal: 17 Oct 2022 (19 weeks, 14 hours, 57 seconds ago) Send patch: 21 Jan 2023 (5 weeks, 2 days, 18 hours ago) Commit patch: 21 Jan 2023 Well, the two “improvements“ here could be, IMHO: a) send patch to guix-patches instead of the bug report itself, b) wait some days between send and commit. > That tendency concerns me as a packager it's not clear for me which > criterias were used to make a division to withdraw the package(s). The > age of project is not always a good measure for example example, > [Common Lisp] ecosystem has quite ancient packages (5-8y old of not > touched since the last commit) but still in active use (check > [pgloader]) >From my point of view, the first rule is if the package still builds or not. If the package is broken, let try to fix and if it is not possible because unmaintained or else, then let drop it. The second rule is if the package is a leaf or not. More dependants the package has and more effort should be put in fixing it, IMHO. The third rule is about security. From my point of view, old packages with known vulnerabilities are not appealing for working on fixing it. Else, if the package still builds, I do not see why it would be removed. Old unmaintained (or barely maintained) packages* are very common in scientific context and they just still works very well. :-) *as linear algebra libraries wrote long time ago using good ol’ Fortran. ;-) Still the state of art. Cheers, simon
