1 |
Hello, everyone. |
2 |
|
3 |
Jalus Bilieyich has submitted the following for the last Council |
4 |
meeting: |
5 |
|
6 |
| Discuss the lack of enough package maintainers to update ebuilds. Many |
7 |
| ebuilds in the Portage tree can be easily marked outdated. |
8 |
|
9 |
Given that the item didn't see any real discussion in the mailing lists, |
10 |
and that it is a non-trivial problem, the Council has decided to bounce |
11 |
it back to the mailing lists in a separate discussion thread. |
12 |
|
13 |
|
14 |
The problem |
15 |
=========== |
16 |
|
17 |
The problem could be summarized shortly: the ebuilds need much more love |
18 |
than they are given right now. This results in some packages being |
19 |
outdated, half-broken and/or using obsolete constructs. In the end, some |
20 |
of the packages start effectively blocking other developers from doing |
21 |
their job (e.g. they can't solve one problem without fixing some other |
22 |
pile of existing problems first). |
23 |
|
24 |
I think we can list a few kinds of packages that need help in Gentoo: |
25 |
|
26 |
1. Packages explicitly listed as not having a maintainer |
27 |
(maintainer-needed) [1]. |
28 |
|
29 |
2. Packages whose maintainer is MIA (including 'dead' projects). |
30 |
|
31 |
3. Packages whose maintainer is not interested in maintaining them |
32 |
(or in some cases even unaware that he is the maintainer). |
33 |
|
34 |
4. Packages whose maintainer is not capable of maintaining them |
35 |
properly (or unwilling to, in some cases). |
36 |
|
37 |
Now, for some details: |
38 |
|
39 |
Ad. 1. We currently have over 1650 m-n packages [1] and the list keeps |
40 |
growing. The advantage of this type is that we have an explicit list |
41 |
and everyone clearly sees that the packages need a new maintainer. We |
42 |
also have some dedicated people who try to help fixing worst issues |
43 |
but they're obviously not capable of doing all the work themselves. |
44 |
|
45 |
Ad. 2. This is somewhat problematic, developers usually notice |
46 |
inactivity after some time and sometimes help out but things are rather |
47 |
suboptimal right now. It can take 3-6 months from developer's |
48 |
disappearance before his packages are announced 'up for grabs' |
49 |
and someone actually interested can take them. |
50 |
|
51 |
Things are even harder when the packages are maintained by projects |
52 |
whose developers are no longer active. |
53 |
|
54 |
Ad. 3. Sometimes developers lose interest or otherwise forget that they |
55 |
maintain some package. This may result in some degradation but the |
56 |
developer usually notices that when a new bug is reported and abandons |
57 |
the package. This is the easier part. |
58 |
|
59 |
The harder part is when packages are maintained by projects who aren't |
60 |
really interested in them. This is especially a problem in herd-style |
61 |
projects that collect large number of packages by a specific topic but |
62 |
the individual project members are really interested in only a subset of |
63 |
them. |
64 |
|
65 |
Ad. 4. This is the hardest part. We have some packages which are |
66 |
maintained but whose maintainers can't really keep up with work. In this |
67 |
case it's usually hard to determine that the maintainer needs help with |
68 |
a specific package, and/or whether he wishes to accept it. |
69 |
|
70 |
What's even worse, there were historical cases when maintainers |
71 |
'claimed' packages but were rather interested in prevented others |
72 |
from the maintenance work ('breaking them') or removing them. |
73 |
At the same time weren't really interested in fixing bugs or updating |
74 |
the packages. |
75 |
|
76 |
|
77 |
Solutions? |
78 |
========== |
79 |
|
80 |
So does anyone have any ideas on what we could realistically do right |
81 |
now to improve things? Few notes from what I've seen: |
82 |
|
83 |
A. Recruiters process new recruits quite smoothly but we don't have many |
84 |
candidates interested in package management. Even then, I don't see |
85 |
every new recruit taking 50+ packages... |
86 |
|
87 |
B. Proxy-maint constantly lacks manpower to process contributions. |
88 |
However, once again we can't expect a lot of packages per maintainer, |
89 |
and we need to account for doubled manpower cost. |
90 |
|
91 |
C. We have a lot of overlays. Some of their maintainers are quite |
92 |
capable. Can we do something about that? |
93 |
|
94 |
D. All above considered, we still haven't dealt with the copyright |
95 |
issues. The work on last draft was stalled one year ago [2]. |
96 |
|
97 |
E. Some of the unmaintained packages are dependencies of other |
98 |
maintained packages in Gentoo. However, developers usually don't want |
99 |
to take them, even if their package is the only revdep. |
100 |
|
101 |
F. We are usually treecleaning packages as they become severely outdated |
102 |
and broken. However, that takes serious amount of work too and usually |
103 |
results in a lot of hostility from other developers (who don't want to |
104 |
maintain the package in question) and users. |
105 |
|
106 |
G. In the past, I've attempted to evaluate the status of projects and to |
107 |
clean some dead up. However, it's a lot of manual labor and it meets |
108 |
with hostility from some of the Gentoo developers. |
109 |
|
110 |
H. For most things related to determining developer inactivity, we have |
111 |
little to no automation. It's easy to tell when a developer stops |
112 |
committing altogether but we have no special help in e.g. determining |
113 |
that some packages are effectively unmaintained (and that would of |
114 |
course meet with hostility). |
115 |
|
116 |
|
117 |
[1]:https://qa-reports.gentoo.org/output/maintainer-needed.html |
118 |
[2]:https://wiki.gentoo.org/wiki/User:Aliceinwire/CopyrightPolicy |
119 |
|
120 |
-- |
121 |
Best regards, |
122 |
Michał Górny |