On Wed, 2019-04-03 at 18:52 -0400, Alec Warner wrote: > On Wed, Apr 3, 2019 at 1:36 PM Michał Górny <mgo...@gentoo.org> wrote: > > Less structured projects often have problems tracking member activity. > > More than once a project effectively died when all members became > > inactive, yet effectively hid the fact that the relevant packages were > > unmaintained and sometimes discouraged more timid developers from fixing > > bugs. > > > > I'm not sure I follow this logic. > > 1) We know who is in every project. > 2) We know the state of every developer. > > We should be able to detect if: > > a) A project has empty. > b) A project has no active developers. > > I don't see how this is markedly different from a package, assigned to no > maintainer. Or a package assigned to a maintainer who is not active.
I'm afraid it's not that simple. Just because someone is active as a Gentoo developer doesn't mean that person is active in this specific project. There's no simple way to know that, and I don't think we should try to figure out complex ways of doing that as they are capable of causing more harm than good with false positives. There is also a deeper problem to this. I believe that having one personally listed as the maintainer (and especially as the sole maintainer) makes that person feel more responsible about the package and its state. If the developer in question doesn't want to maintain it anymore, 'up for grabs' are quite likely. On the other hand, I honestly doubt most of the projects regularly look for unmaintained packages. If a project's developer loses interest in a particular package, the developer can easily assume someone else will take care of it now. Which sometimes happens and sometime does not. There is also another problem with assumptions I myself make as an Undertaker. When a developer is inactive and package reassignment happens, I usually don't remove that developer from all projects, and instead just look for projects that have no other developers. After all, the purpose is to make sure packages aren't left unmaintained, and removing developer from active projects doesn't serve that goal. However, as you can see this way I can easily end up leaving a project consisting solely of inactive developers because I lack the necessary context. > So the solution here seems to be to fix the tools to detect this situation > and make it clearer that the package has no active maintainer? Better looks are always welcome, and I say thankya if you can deliver them. However, as I said they won't solve the problem completely. [...] > > Firstly, they usually tend to include packages that none of the project > > members is actually interested in maintaining. This also includes > > packages added by other developers (let's shove it in here, it matches > > their job description!) or packages leftover from other developers > > (where the project was backup maintainer). This means having a lot of > > packages that seem to have a maintainer but actually don't. > > > > I have a lot of empathy for this point FWIW. Tooling can find empty / > abandoned projects, but we cannot do things like clearly say "This package > shouldn't be in this project" > or "This package is not actually maintained by a project". > > One rule we might use here is that packages always need at least a single > human maintainer, and the project just an annotation; but doesn't affected > maintainer status. > So e.g. if there are 8 competing cron implementations, "cron-team" can't > maintain all 8, they have to find individual humans to vouch for each[0]. I don't think we want to impose this on all projects since -- as I mentioned -- many of them make sense as co-maintaining arbitrary packages. And then, I don't think we can really impose it on only some of the projects. > > Secondly, they frequently lack proper structure and handling of leaving > > members. Therefore, whenever a member maintaining a specific set of > > packages leaves, it is possible that the number of not-really-maintained > > packages increases. > > > > Thirdly, they tend to degenerate and become defunct (much more than > > projects that make sense). Then, the number of not-really-maintained > > packages ends up being really high. > > > > My goal here is to make sure that we have clear and correct information > > about package maintainers. Most notable, if a package has no active > > maintainer, we really need to have 'up for grabs' issued and package > > marked as maintainer-needed, rather than hidden behind some project > > whose members may not even be aware of the fact that they're its > > maintainers. > > > > What do you think? > > > > > [0] This is itself a question the project needs to decide for itself; does > every package need to be maintained actively? Some might answer no, and > maybe running for months / years without a maintainer is OK for Gentoo. Its > not an opinion I personally hold, but I suspect some community members do > hold it. Herds / Projects help Gentoo scale and enable 160 humans to > maintain 19,600 packages. Taking this away will likely affect the number of > packages in the tree as maintainers scale down their stake in the tree. > I'm not sure I follow this. We're not discussing removing those packages. Rather, whether they should be explicitly marked as lacking maintainer vs. hidden behind a project. -- Best regards, Michał Górny
signature.asc
Description: This is a digitally signed message part
