On Thu, 12 Nov 2020 at 18:53, Kevin Kofler via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
--
Stephen J Smoogen.
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
