Re: unmaintained packages hidden by team maintenance (was Re: Bits from the DPL)

Simon Josefsson <[email protected]> Sat, 07 Feb 2026 10:04:09 +0100
Newsgroups	gmane.linux.debian.devel.project
Message-ID	<[email protected]>
Otto Kekäläinen <[email protected]> writes:

> Hi!
>
>> >>>Do you (or anyone else) update the Uploaders field?  In what way?
>> >>
>> >> I feel like I probably should in some way, but at the moment I basically
>> >> don't unless I particularly feel inclined to take over primary
>> >> maintenance of that particular package.
> ..
>> It seems to me that the Uploaders: fields doesn't really reflect any
>> relevant information, or at least none that is kept up to date.
>>
>> Is there any reason we couldn't make this change to policy?
>
> I use the Uploaders field like described in the Policy, and add myself
> as Uploader on packages where I am willing to take responsibility like
> others describe above. Please don't change the meaning or remove the
> Uploaders field.
>
> On the contrary, I would actually ask you to consider using it more
> often. For example you have done all golang-go.crypto uploads in
> (nearly) the past year, but you didn't add yourself as Uploader

Do Policy say anything which suggest that?  What I find is this:

Section 3.3
https://www.debian.org/doc/debian-policy/ch-binary.html#the-maintainer-of-a-package

   If the maintainer of the package is a team of people with a shared
   email address, the Uploaders control field must be present and must
   contain at least one human with their personal email address. See
   Uploaders for the syntax of that field.

I think golang-go.crypto both follow the letter and spirit of that
recommendation.

Section 5.6.3
https://www.debian.org/doc/debian-policy/ch-controlfields.html#uploaders

   List of the names and email addresses of co-maintainers of the
   package, if any. If the package has other maintainers besides the one
   named in the Maintainer field, their names and email addresses should
   be listed here. The format of each entry is the same as that of the
   Maintainer field, and multiple entries must be comma separated.

   This is normally an optional field, but if the Maintainer control
   field names a group of people and a shared email address, the
   Uploaders field must be present and must contain at least one human
   with their personal email address.

I think the letter of this is followed for golang-go.crypto too.

If it follows the spirit of the text depends on what is meant by
"co-maintainer".  I suspect you have one interpretation in mind when you
read it.

This paragraph is the ONLY use of the word "co-maintainer" in the Debian
Policy manual, from what I can tell.  So what it is supposed to mean
isn't terribly clear.

What DO we want "co-maintainer" to mean?  How do you define it?

I wouldn't necessarily consider myself a co-maintainer of
golang-go.crypto since I prefer to consider myself part of a team that
maintains packages.  And preferrably the team is "Debian" rather than
"Debian Go Team", but that is mostly semantics.  The few
golang-go.crypto uploads I've done are mostly drive-by uploads because
other packages needed functionality from newer golang-go.crypto.  I have
only contributed ~0.5% of the its debian/ history:

jas@frallan:~/dpkg/golang-go.crypto$ git ls-files debian|xargs -n1 git blame|wc -l
31757
jas@frallan:~/dpkg/golang-go.crypto$ git ls-files debian|xargs -n1 git blame|grep 'Simon Josefsson'|wc -l
168
jas@frallan:~/dpkg/golang-go.crypto$ 

However I believe the entire concept of Maintainer/Uploader fields in
Debian is a gigantic bike shed.  It can be part of an explaination of
some poor social behaviour historically (e.g., systemd, or almost
anything involving any cross-package co-ordination).  These problems
aren't technical.  Thus we can't solve them fully with technical
improvements.  As they are currently defined, I believe dropping
Maintainer/Uploader fields from the debian policy manual is the simplest
improvement.  Or at least make them optional.  I would agree that
sometimes social problems can be mitigated by technical clarifications
or changes, but I think that would involve some serious work and I don't
see anyone working on that.

/Simon
signature.asc (application/pgp-signature, 1.2 KB)