1 |
On Wed, 2019-04-03 at 18:52 -0400, Alec Warner wrote: |
2 |
> On Wed, Apr 3, 2019 at 1:36 PM Michał Górny <mgorny@g.o> wrote: |
3 |
> > Less structured projects often have problems tracking member activity. |
4 |
> > More than once a project effectively died when all members became |
5 |
> > inactive, yet effectively hid the fact that the relevant packages were |
6 |
> > unmaintained and sometimes discouraged more timid developers from fixing |
7 |
> > bugs. |
8 |
> > |
9 |
> |
10 |
> I'm not sure I follow this logic. |
11 |
> |
12 |
> 1) We know who is in every project. |
13 |
> 2) We know the state of every developer. |
14 |
> |
15 |
> We should be able to detect if: |
16 |
> |
17 |
> a) A project has empty. |
18 |
> b) A project has no active developers. |
19 |
> |
20 |
> I don't see how this is markedly different from a package, assigned to no |
21 |
> maintainer. Or a package assigned to a maintainer who is not active. |
22 |
|
23 |
I'm afraid it's not that simple. Just because someone is active |
24 |
as a Gentoo developer doesn't mean that person is active in this |
25 |
specific project. There's no simple way to know that, and I don't think |
26 |
we should try to figure out complex ways of doing that as they are |
27 |
capable of causing more harm than good with false positives. |
28 |
|
29 |
There is also a deeper problem to this. I believe that having one |
30 |
personally listed as the maintainer (and especially as the sole |
31 |
maintainer) makes that person feel more responsible about the package |
32 |
and its state. If the developer in question doesn't want to maintain it |
33 |
anymore, 'up for grabs' are quite likely. |
34 |
|
35 |
On the other hand, I honestly doubt most of the projects regularly look |
36 |
for unmaintained packages. If a project's developer loses interest |
37 |
in a particular package, the developer can easily assume someone else |
38 |
will take care of it now. Which sometimes happens and sometime does |
39 |
not. |
40 |
|
41 |
There is also another problem with assumptions I myself make |
42 |
as an Undertaker. When a developer is inactive and package reassignment |
43 |
happens, I usually don't remove that developer from all projects, |
44 |
and instead just look for projects that have no other developers. After |
45 |
all, the purpose is to make sure packages aren't left unmaintained, |
46 |
and removing developer from active projects doesn't serve that goal. |
47 |
However, as you can see this way I can easily end up leaving a project |
48 |
consisting solely of inactive developers because I lack the necessary |
49 |
context. |
50 |
|
51 |
> So the solution here seems to be to fix the tools to detect this situation |
52 |
> and make it clearer that the package has no active maintainer? |
53 |
|
54 |
Better looks are always welcome, and I say thankya if you can deliver |
55 |
them. However, as I said they won't solve the problem completely. |
56 |
|
57 |
[...] |
58 |
|
59 |
> > Firstly, they usually tend to include packages that none of the project |
60 |
> > members is actually interested in maintaining. This also includes |
61 |
> > packages added by other developers (let's shove it in here, it matches |
62 |
> > their job description!) or packages leftover from other developers |
63 |
> > (where the project was backup maintainer). This means having a lot of |
64 |
> > packages that seem to have a maintainer but actually don't. |
65 |
> > |
66 |
> |
67 |
> I have a lot of empathy for this point FWIW. Tooling can find empty / |
68 |
> abandoned projects, but we cannot do things like clearly say "This package |
69 |
> shouldn't be in this project" |
70 |
> or "This package is not actually maintained by a project". |
71 |
> |
72 |
> One rule we might use here is that packages always need at least a single |
73 |
> human maintainer, and the project just an annotation; but doesn't affected |
74 |
> maintainer status. |
75 |
> So e.g. if there are 8 competing cron implementations, "cron-team" can't |
76 |
> maintain all 8, they have to find individual humans to vouch for each[0]. |
77 |
|
78 |
I don't think we want to impose this on all projects since -- |
79 |
as I mentioned -- many of them make sense as co-maintaining arbitrary |
80 |
packages. And then, I don't think we can really impose it on only some |
81 |
of the projects. |
82 |
|
83 |
> > Secondly, they frequently lack proper structure and handling of leaving |
84 |
> > members. Therefore, whenever a member maintaining a specific set of |
85 |
> > packages leaves, it is possible that the number of not-really-maintained |
86 |
> > packages increases. |
87 |
> > |
88 |
> > Thirdly, they tend to degenerate and become defunct (much more than |
89 |
> > projects that make sense). Then, the number of not-really-maintained |
90 |
> > packages ends up being really high. |
91 |
> > |
92 |
> > My goal here is to make sure that we have clear and correct information |
93 |
> > about package maintainers. Most notable, if a package has no active |
94 |
> > maintainer, we really need to have 'up for grabs' issued and package |
95 |
> > marked as maintainer-needed, rather than hidden behind some project |
96 |
> > whose members may not even be aware of the fact that they're its |
97 |
> > maintainers. |
98 |
> > |
99 |
> > What do you think? |
100 |
> > |
101 |
> > |
102 |
> [0] This is itself a question the project needs to decide for itself; does |
103 |
> every package need to be maintained actively? Some might answer no, and |
104 |
> maybe running for months / years without a maintainer is OK for Gentoo. Its |
105 |
> not an opinion I personally hold, but I suspect some community members do |
106 |
> hold it. Herds / Projects help Gentoo scale and enable 160 humans to |
107 |
> maintain 19,600 packages. Taking this away will likely affect the number of |
108 |
> packages in the tree as maintainers scale down their stake in the tree. |
109 |
> |
110 |
|
111 |
I'm not sure I follow this. We're not discussing removing those |
112 |
packages. Rather, whether they should be explicitly marked as lacking |
113 |
maintainer vs. hidden behind a project. |
114 |
|
115 |
-- |
116 |
Best regards, |
117 |
Michał Górny |