Sam James wrote: > > Rich Freeman <ri...@gentoo.org> writes: > >> On Tue, Sep 12, 2023 at 9:36 AM Eddie Chapman <ed...@ehuk.net> wrote: >> >>> in Gentoo. Have any of these 4 maintainers publicly said (anywhere) >>> that they are not interested in being maintainers anymore (which is >>> fine if that is the case)? We're not talking here about a lone >>> maintainer of some peripheral package that's disappeared leaving an >>> orphaned package. >> >> It isn't like somebody is censoring the lists or waging commit wars on >> the metadata.xml/mask file. If somebody was eager to maintain it I'm >> sure they'd have spoken up. >> >>> I'm an outsider to Gentoo development (just a heavy user for over a >>> decade both personally and professionally) so I might have missed >>> something. I just find it puzzling. >> >> I'm not puzzled by what is going on, or by your email, because it >> happens basically anytime a high-profile package is treecleaned. Yes, >> Gentoo is about choice, but somebody has to actually do work to make >> the choices viable. There are always more people interested in using >> software than maintaining it. The frustration is completely >> understandable, but also kinda unavoidable. >> >> Repo QA standards don't mean that it has to barely work for your >> specific use case. The package has to deal with compatibility issues >> with stuff you don't use as well, which is why maintaining a system >> package can be hard work. It is usually less of an issue for more >> ordinary applications, which tend to have fewer interactions. If it is >> "good enough" for you as it is, then just move it to a private >> overlay and keep using it. You probably would need to override a virtual >> or two as well. Or publish your work somewhere others can use it. > > Yes. We value having a coherent system with decent UX and we have > to choose what we can support. Users are free to override those choices in > local repositories - and if they want advice on the best way to do so, > they're free to ask.
Yes I regularly do this if there is a piece of software not in the tree, I have a local repo full of stuff. But this argument doesn't hold as much weight when it comes to a package like this which is integrated in the core of the system. People who really want to continue using it are going to experience a lot of pain trying to maintain it for themselves out of tree, much more so than they would normally. That's one reason why I think the decision deserves more scrutiny.
