[gentoo-dev] The problem of unmaintained packages in Gentoo

[Michał Górny]

Hello, everyone.

Jalus Bilieyich has submitted the following for the last Council
meeting:

| Discuss the lack of enough package maintainers to update ebuilds. Many
| ebuilds in the Portage tree can be easily marked outdated.

Given that the item didn't see any real discussion in the mailing lists,
and that it is a non-trivial problem, the Council has decided to bounce
it back to the mailing lists in a separate discussion thread.


The problem
===========

The problem could be summarized shortly: the ebuilds need much more love
than they are given right now. This results in some packages being
outdated, half-broken and/or using obsolete constructs. In the end, some
of the packages start effectively blocking other developers from doing
their job (e.g. they can't solve one problem without fixing some other
pile of existing problems first).

I think we can list a few kinds of packages that need help in Gentoo:

1. Packages explicitly listed as not having a maintainer
   (maintainer-needed) [1].

2. Packages whose maintainer is MIA (including 'dead' projects).

3. Packages whose maintainer is not interested in maintaining them
   (or in some cases even unaware that he is the maintainer).

4. Packages whose maintainer is not capable of maintaining them 
   properly (or unwilling to, in some cases).

Now, for some details:

Ad. 1. We currently have over 1650 m-n packages [1] and the list keeps
growing. The advantage of this type is that we have an explicit list
and everyone clearly sees that the packages need a new maintainer. We
also have some dedicated people who try to help fixing worst issues
but they're obviously not capable of doing all the work themselves.

Ad. 2. This is somewhat problematic, developers usually notice
inactivity after some time and sometimes help out but things are rather
suboptimal right now. It can take 3-6 months from developer's
disappearance before his packages are announced 'up for grabs'
and someone actually interested can take them.

Things are even harder when the packages are maintained by projects
whose developers are no longer active.

Ad. 3. Sometimes developers lose interest or otherwise forget that they
maintain some package. This may result in some degradation but the
developer usually notices that when a new bug is reported and abandons
the package. This is the easier part.

The harder part is when packages are maintained by projects who aren't
really interested in them. This is especially a problem in herd-style
projects that collect large number of packages by a specific topic but
the individual project members are really interested in only a subset of
them.

Ad. 4. This is the hardest part. We have some packages which are
maintained but whose maintainers can't really keep up with work. In this
case it's usually hard to determine that the maintainer needs help with
a specific package, and/or whether he wishes to accept it.

What's even worse, there were historical cases when maintainers
'claimed' packages but were rather interested in prevented others
from  the maintenance work ('breaking them') or removing them.
At the same time weren't really interested in fixing bugs or updating
the packages.


Solutions?
==========

So does anyone have any ideas on what we could realistically do right
now to improve things? Few notes from what I've seen:

A. Recruiters process new recruits quite smoothly but we don't have many
candidates interested in package management. Even then, I don't see
every new recruit taking 50+ packages...

B. Proxy-maint constantly lacks manpower to process contributions.
However, once again we can't expect a lot of packages per maintainer,
and we need to account for doubled manpower cost.

C. We have a lot of overlays. Some of their maintainers are quite
capable. Can we do something about that?

D. All above considered, we still haven't dealt with the copyright
issues. The work on last draft was stalled one year ago [2].

E. Some of the unmaintained packages are dependencies of other
maintained packages in Gentoo. However, developers usually don't want
to take them, even if their package is the only revdep.

F. We are usually treecleaning packages as they become severely outdated
and broken. However, that takes serious amount of work too and usually
results in a lot of hostility from other developers (who don't want to
maintain the package in question) and users.

G. In the past, I've attempted to evaluate the status of projects and to
clean some dead up. However, it's a lot of manual labor and it meets
with hostility from some of the Gentoo developers.

H. For most things related to determining developer inactivity, we have
little to no automation. It's easy to tell when a developer stops
committing altogether but we have no special help in e.g. determining
that some packages are effectively unmaintained (and that would of
course meet with hostility).


[1]:https://qa-reports.gentoo.org/output/maintainer-needed.html
[2]:https://wiki.gentoo.org/wiki/User:Aliceinwire/CopyrightPolicy

-- 
Best regards,
Michał Górny