Many packages are team-maintained these days, and they typically have
the following control fields:

Maintainer: Debian Foo Team <pkg-foo@example.com>
Uploaders: Ex Ample <ex@example.com>, X Ample <x@example.com>

It would be very helpful if bug reports were forwarded to the
Uploaders as well as the Maintainer.

Receiving a direct notification of the bug would make team members
more aware, and feel more personally responsible than now, when the
Maintainer address is often a mailing list, that people may read
through Gmane or in a different way than personal mail.

If the maintainer is not given as a mailing list, then the uploaders
should all subscribe to the PTS for a given package.


Don Armstrong

Agreed, but considering human nature, I think people forget to take this extra
step, or are unaware of it. (Not sure if it's even explicitly stated
anywhere).

So the development process would probably benefit if this could be enforced.
Perhaps it could happen by default, and then people could opt out?

Marcus

tag 397761 wontfix
thanks

It should be stated in the developers reference, but I'm not sure if
it is or not.
to the Maintainer, there is no way to opt out of it.

It's far easier to subscribe to the pts and unsubscribe if Maintainer
is not a list. [It should at least be an address that goes to a real
person.]


Don Armstrong

Hi,

I agree that it is hard for Uploaders to opt out if they get mailed
automatically.  But despite the mailing issue I think there should
be an option in the CGI interface to query for an address mentioned
in the list of uploaders.  What I would call perfect is an option

     maint+upload=tille@debian.org

which should list all those packages where I'm listed in Maintainer
or Uploaders.  This gives you all packages that might concern you.

What do you think?

Kind regards

         Andreas.

Hi!
Could you please reconsider this wontfix?  It's been over ten years since
you made this decision, and I think Debian has changed since.  Not being
told about a RC bug in your own package is a severe issue, and requiring
an explicit subscription for something that usually works is not a thing
one would think of or remember.  The concept of Uploaders is no longer a
novelty it was at the time.

The only reason given is "there's no way to opt out".  But there is!

sed "/Uploaders:/ s/[A-Za-z0-9 ]*<$EMAIL>,?//" -i debian/control

I fail to see what business one has being an Uploader without being
interested in bugs in that package.


When mentioned on IRC, it didn't sound like those awake were happy with the
current behaviour either.

Hi,

I second Adam Borowski in

On Fri, 21 Apr 2017 13:19:56 +0200 Adam Borowski <kilobyte@angband.pl>
wrote:

Policy 5.6.3 states the Uploaders field is
any.

Thus an uploader *is* a maintainer, just not the principle one. And maintainers
ought to monitor bug reports.

On Tue, 13 Mar 2007 23:50:55 -0700 Don Armstrong <don@donarmstrong.com> wrote:

In the Rust team it's far more difficult because there are thousands of
packages, each of us being the Uploaders of tens of them on average, so it's
quite cumbersome to subscribe to their PTS, and more easily forgotten on first
uploads.

It's an unfortunate consequence of lowered barrier upstream that introduced an
order of magnitude more packages than 15 years ago.

Current team maintenance practice sets the Maintainer field to a team address,
which effectively means all team maintained packages have their bug reports
sent to it.

Because of the sheer number of packages in the Rust team, their Maintainer field
is left to be pkg-rust-maintainers@alioth-lists.debian.net, while discussions
happen on debian-rust@lists.debian.org. Changing Maintainer to point to the
latter would flood the list and our inboxes with upload result emails. It might
be feasible to direct submitters to X-Debbugs-Cc: the latter, but that requires
prior knowledge, while those without still become unnoticed.

I imagine this is a common problem in teams that practice team maintenance and
own a rather large number of packages.

As Adam said, things have changed. Please reconsider the wontfix.

Dear -devel,

Way back in 2006 (19 years ago), #397761 was submitted to request for BTS to forward bug reports also to the Uploaders.

Dan Armstrong (don) wontfix'd it after stating that, quote:

and

Andreas Tille (tille) suggested that there could/should be a way to list bug reports of packages for which one is an Uploader.

Adam Borowski (kilobyte) argued (in 2017, eleven years after, eight years until now) that things has changed after all these years;

also suggested that one could surely "opt out" by removing themself from Uploaders.

I added that a. team maintenance means hundreds or thousands emails sent to the team Maintainer address, many of which are probably for packages a particular maintainer doesn't care about, and b. it's a hassle and often forgotten to subscribe to all those tens or hundreds of packages one maintains. Well, that can be automated, so this is not a strong argument, but option 2 would still make it better.

Options I can think of:

1. Let BTS forward to Uploaders

Reiterating my point in previous reply to #397761:

Policy 5.6.3 states the Uploaders field is
any.

Policy didn't clarify, but if we consider "co-maintainer" a person who does the same job as the one listed as Maintainer, just not listed there, then this person is effectively also a maintainer. And maintainers ought to monitor and deal with bug reports.

If it's so decided that BTS still shouldn't forward to Uploaders,

2. Let PTS automatically subscribe maintainers to packages they are Uploaders of

In the current version of the PTS, subscribing to a package means either a. after logging in, clicking the Subscribe button on tracker.debian.org/pkg/foo, and optionally changing topics ("keywords"); b. with devscripts installed, running `pts-subscribe foo [--forever]`, with no way to change topics. For each package one maintains, this has to be done once.

Instead of asking every maintainer to repeat that for every package they maintains, we can have the PTS automatically subscribe them to packages they are, and in the future, when they become, an Uploader of.

Conversely, also unsubscribe those who are removed from Uploaders of a package. Though it's possible some want to continue receiving updates of a package even after stepping down as its Uploader.

3. Add the option to subscribe to a package on BTS

This would at least allow people who don't/wouldn't use PTS to receive new bug reports for packages they care about. PTS is a separate service that happens to forward BTS bug reports, in a way.

4. Better ideas?

(I'm also confused by the fact that follow-ups to bug reports aren't forwarded to submitters by default, but the submitter must X-Debbugs-Cc themselves, but then which is basically the default behavior of reportbug(1) now IIRC, but that's for another time.)

Quoting Blair Noctis (2025-03-02 18:06:49)
[...]
[...]

What happened to "If the maintainer is not given as a mailing list" in
your added concerns?

The cases you talk about with Uploader involved in hundreds of packages,
are you then expanding to also discuss larger teams with a mailinglist
as Uploader?

If you instead talk about packages where Maintainer is effectively
/dev/null then you got bigger problems than Uploader needing busywork!

 - Jonas

I will just note that I have been a Debian Developer for almost 30 years,
and a few months after I started maintaining varnish and other related
packages I am still not sure if I did everything needed to receive one
and only one copy of new bug reports.
So I would welcome some rationalization in this area...

Hi all,

I am in strong favor of 1., letting BTS forward to Uploaders. I'm
Uploader for a few tens of (team-maintained) packages, most of which I
don't particularly care about since I only introduced them as
dependencies, and I'm not going to subscribe to all of them. Still, I do
feel responsible for their well-being, so I really don't understand why
I shouldn't (and don't) receive bug reports that concern them.

At this stage, this is how it's worked for me. I introduce a package in
Debian (usually within some team, which means the team is Maintainer and
I'm Uploader), I wait for it to pass the NEW queue, then if I care
enough about it (which usually means it's a leaf package instead of a
dependency) I subscribe to it. Then I wait for the confirmation email, I
answer with an acceptance email (which the PTS requires) and I archive
the confirmation email so as not to clog my incoming folder. Finally I
create a folder and a filter for the corresponding tracker.d.o mailing
list so that the tens of emails I receive each day from Debian-related
activities can remain manageable. I'm not going to do this dance for
every single package for which I am Uploader. I am very happy to do it
for those I actually care about, and for those only.

At present the way I've dealt with bugs in packages for which I'm
Uploader (but to which I'm not subscribed) is either by reading every
single bug report addressed to the Team mailing list -- of which there
are very many, so I don't actually know if I always caught them this
way; additionally, being Uploader for tens of packages, I may not
immediately remember all their names -- or by periodically checking for
the bug count in the "Bugs" column in my DDPO -- which assumes I
remember the bug count of every package I am Uploader for [1]. In the
latter case there is no time frame for when that will happen.


Additionally, it happened to me a few times that I filed (or engaged
with) bugs for packages whose maintainer was listed as Uploader, which
resulted in them simply being unaware of the bug. This included one bug
at severity grave (fortunately unrelated to security, and probably
better classified as serious) which went unanswered for ~ 1 month and
because of which a number of autoremovals (including of packages I
co-maintain) were scheduled. Because of this I spent weeks monitoring
that bug, until I finally realized what was happening and cc'ed the
actual maintainer, who then answered saying he was completely unaware of
the bug and solved it within less than an hour.


I don't think option 3., add the option to subscribe to a package on
BTS, is enough. It should be automatic. Maybe option 2., let PTS
automatically subscribe maintainers to packages they are Uploaders of,
could do, but since PTS sends email notifications for far more stuff
than bug reports we should really just want to have at least 1.
(automatic BTS submissions) at the bare minimum. I don't personally feel
the need to have more options.


Cheers!


[1] Which incidentally I do at this time, but this is just a lucky and
temporary coincidence made possible by my knowledge that there's a
single bug I can't close at present, so the others are those I should
actively engage with.

interacted with by email[1], and you can do a whole lot of things
through that (including setting the keywords). I used the following to
subscribe to all my packages:

#!/usr/bin/env fish
set name "Maytham Alsudany"
sudo apt update
set packages $(grep-dctrl -n -F Uploaders -w $name -s Package \
  /var/lib/apt/lists/deb.debian.org_debian_dists_unstable_main_source_Sources)
for package in $packages
  echo "subscribe $package"
  echo "keyword $package = bts"
end | mail control@tracker.debian.org

Alternatively, if you've already subscribed to some packages, and you
want to change all their keywords so you only get BTS emails, then you
can send "keyword = bts" to change your keyword settings for all your
subscriptions.

Not sure what you meant.
If "the maintainer is not given as a mailing list",
my understanding is that it then is given as an individual,
which doesn't have a problem here.
I'm not aware of a situation where the maintainer is neither a mailing list,
including list-like addresses like @p.d.o or @tracker.d.o,
nor an individual.

I was indeed talking about such cases,
where the Maintainer is set to the mailing list of a larger team,
and individual human maintainers are Uploaders.

I talked about situations where Maintainer is effectively a catch-all,
and someone thinks it's too catch-all to catch for themself.
It's different from the /dev/null situation you said,
which to my understanding means this someone does not check it at all.
FWIW, as a someone myself,
I don't subscribe to certain lists listed as Maintainer,
but still check them from time to time.

X-Debbugs-CC does not forward replies to bug reports. People replying
to bug reports need to explicitly CC the bug submitter or hope that
the bug submitter is already subscribed because it is a package they
maintain. The workflow to manually subscribe to individual bugs is
tedious enough that I only do it occasionally for bugs I am interested
in, usually where I am not the bug submitter.

Thank you,
Jeremy Bícha

On Mon, 03 Mar 2025, Blair Noctis wrote:n

This is still correct. Because the way subscriptions in debbugs is
implemented isn't complete, there's no way to allow people to opt in or
opt out of messages both for submitters, uploaders, or random
bystanders.

The PTS solves this to some degree, but actually fixing this correctly
requires a level of code change to the current version of debbugs which
isn't likely to happen any time soon. [This is a design issue which I
hope to eventually address, but my track record here is really bad.]