Bug#798476: Returning to the requirement that Uploaders: contain humans
On 08/03/2017 08:58 PM, Russ Allbery wrote:
> Jonas Smedegaard <jonas@jones.dk> writes:
>
>> Do the MIA team also track MIA teams?
>
>> My concern is that packages without maintainers may go unnoticed when
>> none of its previously active maintainers were tracked individually.
>
>> For such detection of abandonment we need not track _all_ active
>> maintainers, but at least one - as individual.
>
> Or track MIA teams, which in a lot of ways is a much easier problem, and
> seems like a worthwhile problem to solve anyway.
>
> I don't feel like dropping the Uploaders field for team-maintained
> packages if the team so chooses will make MIA tracking substantially
> harder, or will make orphaned package tracking substantially harder.
I wonder whether we are framing this in the right way anyway. There
are two orthogonal questions in my mind:
- is a specific person MIA?
- is a package still maintained?
There is not necessarily a direct relation between both questions.
Take for example a person who someone in this thread called
"partially MIA" (I don't like that term btw.): they still actively
maintain a bunch of packages, but have dropped the ball on another
package.
On the other hand you could have a package that has
Maintainer: some team and Uploaders: some person, where "some
person" is actually MIA, but the rest of the team is still actively
maintaining the package.
The main problem I see with Uploaders: is that it's often not really
up to date. So I do think that it might be a good idea to track the
people who are responsible for a package outside of the package
itself in some kind of central database that is not tied to package
uploads. This could also make it easy to query that database. On the
other hand I would not want to maintain a team membership list for
this purpose, but track by package, because while there are small
teams where everyone is responsible for every single package, there
are also larger teams where not everyone cares about every single
package that the team maintains. So I don't think the Uploaders:
field in a package is useless, I just think the current way of
storing that information is not the best way to do so. But until
such a central database is ready for usage, I don't think it would
be wise to drop Uploaders: at the moment, because otherwise that
information can't be tracked at all.
To help with the question of whether a package is still being
actively maintained, let me frame it in this way: I think it is
not completely unreasonable to say that _most_ packages will be
updated at least once every 12 months in sid or experimental. (The
precise number is subject to bikeshedding.) Of course that's not
true for every package, there are some packages which don't require
updates that often. So what one could do is the following: a
package is considered to be actively maintained if a maintainer (or
team) upload has happened in the last 12 months. (NMUs don't count.)
If that is not the case, after 12 months an email is automatically
sent to the maintainer/uploaders to ask whether they are still
actively maintaining the package. They then have 3 months to respond
by either uploading a new version to sid or experimental, or
replying to that email that "yes, the package is still being
actively maintained, there was just no reason to update it recently".
Then there could be a clear way of determining what packages are
candidates for orphanning (while the email + reply logic should be
automatic, the orphanning should only be done after a human looks
that over). Obviously the precise amount of time can be bikeshedded,
but I do believe that the general concept is something sensible.
Becuase if one is indeed actively maintaining a package, then they
should be able to reply to an email every year or so. (Especially
if just doing "reply" + "send" is sufficient, like with mailing
list confirmations.)
Just to throw some ideas out there.
Regards,
Christian
Reply to: