Bug#397761: bugs.debian.org: please forward bug reports to Uploaders also

[Blair Noctis]

Hi,

I second Adam Borowski in

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.

Policy 5.6.3 states the Uploaders field is

List of the names and email addresses of co-maintainers of the package, if

any.

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

tag 397761 wontfix
thanks

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

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).

It should be stated in the developers reference, but I'm not sure if
it is or not.

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

The problem is that if I start sending mails to Uploaders: in addition
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.]

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-***@alioth-lists.debian.net, while discussions
happen on debian-***@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.

[Blair Noctis]

Dear -devel,

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

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

and

The problem is that if I start sending mails to Uploaders: in addition
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.]

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;

(...) 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.

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

List of the names and email addresses of co-maintainers of the package, if

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.)

--
Sdrager,
Blair Noctis

[Jonas Smedegaard]

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

Post by Blair Noctis

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

[...]

Post by Blair Noctis
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.

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

[Blair Noctis]

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

Post by Blair Noctis

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

[...]

Post by Blair Noctis
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.

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

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.

Post by Jonas Smedegaard
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?

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.

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

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.

--
Sdrager,
Blair Noctis

[Marco d'Itri]

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...

[NoisyCoil]

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.

[Maytham Alsudany]

Post by Blair Noctis
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.

There is a third option that is being missed here: the tracker can be
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 ***@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.