Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: gentoo-dev <gentoo-dev@l.g.o>
Subject: [gentoo-dev] The problem of unmaintained packages in Gentoo
Date: Wed, 20 Dec 2017 16:49:15
1 Hello, everyone.
3 Jalus Bilieyich has submitted the following for the last Council
4 meeting:
6 | Discuss the lack of enough package maintainers to update ebuilds. Many
7 | ebuilds in the Portage tree can be easily marked outdated.
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.
14 The problem
15 ===========
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).
24 I think we can list a few kinds of packages that need help in Gentoo:
26 1. Packages explicitly listed as not having a maintainer
27 (maintainer-needed) [1].
29 2. Packages whose maintainer is MIA (including 'dead' projects).
31 3. Packages whose maintainer is not interested in maintaining them
32 (or in some cases even unaware that he is the maintainer).
34 4. Packages whose maintainer is not capable of maintaining them
35 properly (or unwilling to, in some cases).
37 Now, for some details:
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.
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.
51 Things are even harder when the packages are maintained by projects
52 whose developers are no longer active.
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.
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.
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.
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.
77 Solutions?
78 ==========
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:
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...
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.
91 C. We have a lot of overlays. Some of their maintainers are quite
92 capable. Can we do something about that?
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].
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.
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.
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.
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).
117 [1]:
118 [2]:
120 --
121 Best regards,
122 Michał Górny


Subject Author
Re: [gentoo-dev] The problem of unmaintained packages in Gentoo nado@××××××××××.be
Re: [gentoo-dev] The problem of unmaintained packages in Gentoo Virgil Dupras <hsoft@×××××××××.net>
Re: [gentoo-dev] The problem of unmaintained packages in Gentoo Christopher Head <chead@×××××.ca>