On Thu, 12 Nov 2020 at 18:53, Kevin Kofler via devel < devel@lists.fedoraproject.org> wrote:
> Matthew Miller wrote: > > Well, except, it clearly *does* work that way. We have many > > lightly-maintained packages in practice. > > Do we really? Which are those packages? > > The one that keeps getting brought up is Tomcat, but I can tell you from > my > personal experience that the Fedora Tomcat package has always been working > just fine (not only as a build dependency, but for its intended use as a > web > application server: I use it to locally test Java web applications). > > The following is to give hypothetical answers to your question about which packages are lightly-maintained. This isn't a statement that they should be split into a light repository but that they are probably not getting the attention that strongly maintained packages have. 1. Any set of packages greater than 5 being maintained by a single packager. There is only so much attention a person can give to software and work with either fixing things directly or pushing those bugs upstream. 2. Any package that has a statistically larger number than the 'average' untouched bugzilla tickets at the autoclose period. 3. Various packages which no-one wants to maintain but end up just in a person's queue because it's a build dependency for the chain of things they do care about. Again I am not saying that they should go into a different repository.. but we have to recognize that they do exist versus constantly sweeping them under the rug with a 'oh that never happens' or a 'I don't see why someone else can't maintain it' or 'if I write enough angry emails to the list someone will pick it up to shut me up.' [All of which I believe i have been guilty of at some point in the last 25 years of working on distros.] > > I think it's better to label them as such and find positive ways to > > encourage the collaboration I think we all agree is best, rather than the > > current state where we basically just pretend that everything is > > maintained with high attention. > > I think that if a maintainer is not able to offer a package the attention > they think it needs, they should ask for help, not mark the package as > unsupported or hidden. That is how the collaborative approach is supposed > to > work. > > Now, if no help shows up, that can only mean one of two things: > * either the package is actually working so well that no help is really > needed, > * or nobody actually cares enough about the package to give it more > attention. > or 3. Nobody wants to take up that responsibility because they feel maxed out already. 4. The package is a complete piece of crap to work with, but fixing it only brings up a long list of complaints from certain people who no one wants to have unless they are paid a lot of money to do so. 5. Everyone wants it to be someone else's problem. We are at the other side of the bell curve of people interested in working on operating systems. There are a larger number of people who have packages but aren't part of Fedora anymore and their emails bouncing or dev/null than we had in the past. We are not seeing a lot of new people coming in... so the number of packages per packager is going to go up. > In both cases, the package is working well enough for what is actually > needed and there is no need to give it any special marking. > > But the situation into which we want to get is that the help is not only > requested by the maintainer, but that comaintainers actually sign up for > it. > But that requires upholding a cooperative environment. Privatizing build > dependencies by marking them as "lightly maintained" achieves the exact > opposite. > > Kevin Kofler > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Stephen J Smoogen.
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
