Bug#397761: Bug reports for Uploaders (was: Re #397761: bugs.debian.org: please forward bug reports to Uploaders also)

[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

[Marc Haber]

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

I only maintain insignificant, small packages, but my packages have the
PTS^wtracker set as maintainer address, and the indivdual uploaders in
uploaders:

Maintainer: Debian Adduser Developers <***@packages.debian.org>
Maintainer: Debian Sudo Maintainers <***@packages.debian.org>

In Salsa, I have set the "Emails on push" Integration to send to
dispatch+***@tracker.debian.org.

I am often surprised by how many people have subscribed those packages
in the tracker.

This is working reasonably well in the absence of easily obtainable
package related mailing list. Especially in adduser, this is being
extensively used for team internal communication, the only disadvantage
being that ***@p.d.o isn't archived. There are no moderation
mechanisms, but that has never been needed in my cases.

In fact, this works so well that we should document that in the new
maintainer's guide.

Greetings
Marc

[Blair Noctis]

On 03/03/2025 01:40, Marc Haber wrote:
(...)
Honestly I never understood how exactly @p.d.o addresses work.
Devref says it's "a simple email alias" that "provides a way to email the maintainer",
"whatever their individual email address (or addresses) may be",
but doesn't tell which kind of email addresses it forwards to.
Nor can I find info at other places, like wiki.d.o.
I always thought ***@p.d.o would forward to the Maintainer of foo,
but setting ***@p.d.o as the Maintainer of foo means forwarding to itself.

(...)

In fact, this works so well that we should document that in the new maintainer's guide.

I'd also appreciate some (clearer) documentation of the @p.d.o addresses,
other than the vague mention in devref.
Policy doesn't seem to describe it,
nor did I succeed searching in wiki.d.o.

--
Sdrager,
Blair Noctis

[Marc Haber]

Post by Blair Noctis
Devref says it's "a simple email alias" that "provides a way to email the maintainer",
"whatever their individual email address (or addresses) may be",
but doesn't tell which kind of email addresses it forwards to.
Nor can I find info at other places, like wiki.d.o.

I think it mainly forwards to the mail addreses that have subscribed
to the package in the Tracker. You have a "Subscribe" button in the
top right corner of the Tracker package.

I usually get three copies of any bug report that is filed against
such a package, but that is more likely to draw my attention, so it's
part of a feature for me.

Post by Blair Noctis
other than the vague mention in devref.
Policy doesn't seem to describe it,
nor did I succeed searching in wiki.d.o.

Does https://qa.pages.debian.net/distro-tracker/ help?

Greetings
Marc

[Blair Noctis]

Post by Marc Haber

Post by Blair Noctis
Devref says it's "a simple email alias" that "provides a way to email the maintainer",
"whatever their individual email address (or addresses) may be",
but doesn't tell which kind of email addresses it forwards to.
Nor can I find info at other places, like wiki.d.o.

I think it mainly forwards to the mail addreses that have subscribed
to the package in the Tracker. You have a "Subscribe" button in the
top right corner of the Tracker package.

It's a likely explanation,
but then Uploaders continue to be ignored.

Post by Marc Haber

Post by Blair Noctis
other than the vague mention in devref.
Policy doesn't seem to describe it,
nor did I succeed searching in wiki.d.o.

Does https://qa.pages.debian.net/distro-tracker/ help?

It only describes,
in the Email Messages section,
that the "contact" keyword forwards emails to ***@packages.debian.org.
I don't see evidence it describes how the address itself works.

Thanks for the help,
though it seems further clarification can only come from p.d.o staff.

--
Sdrager,
Blair Noctis

[Adam D. Barratt]

Post by Blair Noctis

[...]

Post by Blair Noctis
Devref says it's "a simple email alias" that "provides a way to
email the maintainer",
"whatever their individual email address (or addresses) may be",
but doesn't tell which kind of email addresses it forwards to.

[...]

Post by Blair Noctis
though it seems further clarification can only come from p.d.o staff.

"Staff" is a weird term to use in free software contexts. :-)

In any case you're looking for
https://salsa.debian.org/webmaster-team/packages/-/blob/debian-master/bin/build-maintainerdb

Regards,

Adam

[Blair Noctis]

Post by Adam D. Barratt

Post by Blair Noctis

[...]

Post by Blair Noctis
Devref says it's "a simple email alias" that "provides a way to
email the maintainer",
"whatever their individual email address (or addresses) may be",
but doesn't tell which kind of email addresses it forwards to.

[...]

Post by Blair Noctis
though it seems further clarification can only come from p.d.o staff.

"Staff" is a weird term to use in free software contexts. :-)

p.d.o is a service, after all ;)

Post by Adam D. Barratt
In any case you're looking for
https://salsa.debian.org/webmaster-team/packages/-/blob/debian-master/bin/build-maintainerdb

Thanks, this seems to be the canonical source of an answer.
Though with my limited Perl knowledge,
I can only see that it
0. reads an override file,
1. searches through the indices/Maintainers file in an archive,
whose naming presumably means the Maintainer field of packages,
2. records found email, but ignores when it ends with @p.d.o or @tracker.d.o,
3. writes remaining email, along with tracker dispatch address, for each package.

So IIUC, @p.d.o address forwards to
1. the Maintainer if it's not again a @p.d.o, nor @tracker.d.o,
2. tracker subscribers.

So if the "staff" agrees,
we can make @p.d.o addresses forward also to Uploaders,
thus with @p.d.o address as Maintainer,
also forwarding bug reports to Uploaders,
achieving the goal.

Aside: I'm amused, and horrified at the same time,
that such a maintainer "database" is a plain text file.

--
Sdrager,
Blair Noctis

[Raphael Hertzog]

(tracker.debian.org maintainer here)

Hi,

Post by Blair Noctis
So if the "staff" agrees,
also forwarding bug reports to Uploaders,
achieving the goal.

I don't really agree. "***@packages.debian.org" is not the canonical
way to reach a package maintainer.

At this point, we have many services mailing maintainers directly and
sending a copy to the package tracker.

I'm the one who tweaked the above script to make it possible to use
***@packages.debian.org or team+***@tracker.debian.org as the Maintainer
of a package.

The goal is clearly to receive all the maintainer emails on
tracker.debian.org and to let anyone receive them from there.

From your initial list, my preferred outcome is to modify
tracker.debian.org so that all Uploaders are automatically subscribed,
that's what has been requested for a long time in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756954

But there are quite a few safeguards (opt-in/opt-out) to put in place
to make this realistic and not generate too many complaints.

For instance, you should not generate a package-subscription if the person is
already part of a package tracker team monitoring the same package, and
each person should be able to opt-out globally or for a specific package.

New/removed subscriptions should be notified by emails to the affected
persons.

Cheers,

[Blair Noctis]

Hi Raphael,

Post by Raphael Hertzog
(tracker.debian.org maintainer here)

Thanks for maintaining the service ;)

Post by Raphael Hertzog
Hi,

Post by Blair Noctis
So if the "staff" agrees,
also forwarding bug reports to Uploaders,
achieving the goal.

way to reach a package maintainer.

As per devref 7.3,
it's a way for *maintainers* to contact other maintainers.
Not really the same as BTS,
which all users are free to use.
So I agree it's not the same as BTS forwarding to Uploaders.
It's really just a sudden thought.

Post by Raphael Hertzog
At this point, we have many services mailing maintainers directly and
sending a copy to the package tracker.
I'm the one who tweaked the above script to make it possible to use
of a package.
The goal is clearly to receive all the maintainer emails on
tracker.debian.org and to let anyone receive them from there.
From your initial list, my preferred outcome is to modify
tracker.debian.org so that all Uploaders are automatically subscribed,
that's what has been requested for a long time in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756954

That would be nice.
Thanks for considering it.

Post by Raphael Hertzog
But there are quite a few safeguards (opt-in/opt-out) to put in place
to make this realistic and not generate too many complaints.
For instance, you should not generate a package-subscription if the person is
already part of a package tracker team monitoring the same package, and
each person should be able to opt-out globally or for a specific package.
New/removed subscriptions should be notified by emails to the affected
persons.

Agreed.
If we are to make the tracker "smart",
these should of course be considered.

Need some hands?

Post by Raphael Hertzog
Cheers,

--
Sdrager,
Blair Noctis

[Raphael Hertzog]

Hi,

Post by Blair Noctis

Post by Raphael Hertzog
From your initial list, my preferred outcome is to modify
tracker.debian.org so that all Uploaders are automatically subscribed,
that's what has been requested for a long time in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756954

That would be nice.
Thanks for considering it.

Heh. It's not really something new, I have been thinking this problem
for a long while already:
https://dep-team.pages.debian.net/deps/dep2/

Some of the thoughts there turned into some of the changes I pushed
forward... but many are still just ideas waiting for people to refresh and
pick them up. :-)

Post by Blair Noctis

Post by Raphael Hertzog
New/removed subscriptions should be notified by emails to the affected
persons.

Agreed.
If we are to make the tracker "smart",
these should of course be considered.
Need some hands?

Yes, definitely! I try to be reactive for reviews but I'm mostly a SPOF
and would love to get some co-maintainers on board over time. Don't
hesitate to ping me on IRC too (I'm buxy there).

https://qa.pages.debian.net/distro-tracker/contributing.html

Cheers,

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

[Andreas Metzler]

On 2025-03-02 Blair Noctis <***@debian.org> wrote:
[...]

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

[...]

Hello,

This should be easily scriptable, using grep-dctrl to find the Packages
you are are uploader for and subscribing by mail.

There is another downside to the BTS sending mails to uploaders. - There
is no simple unsubscribe, it would need a sourceful upload.

cu Andreas

[Blair Noctis]

Post by Andreas Metzler
[...]

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

[...]
Hello,
This should be easily scriptable, using grep-dctrl to find the Packages
you are are uploader for and subscribing by mail.

Indeed.
Though one downside is that one needs to remember to do it.
One way is to periodically run such a script.
Or the service could be nice and do it for you.
One important aspect of software design is,
to let the software do the right thing by default,
aka sane defaults,
unless subscribing most maintainers to their packages for bug reports,
is not sane.

Post by Andreas Metzler
There is another downside to the BTS sending mails to uploaders. - There
is no simple unsubscribe, it would need a sourceful upload.

I wonder who would bother to add themself to Uploaders of a package,
but then refuse to read bugs related to it.
Or if one really wants to,
they could set up a filter in their email client and/or server,
to filter out such emails.
This requires extra work,
just like your suggestion above.

Post by Andreas Metzler
cu Andreas

--
Sdrager,
Blair Noctis

[Andrey Rakhmatullin]

Post by Blair Noctis

Post by Andreas Metzler
There is another downside to the BTS sending mails to uploaders. - There
is no simple unsubscribe, it would need a sourceful upload.

I wonder who would bother to add themself to Uploaders of a package,
but then refuse to read bugs related to it.

Packages accumulate Uploaders, because people who lose interest in a
package or in Debian as a whole rarely remove themselves.

[Marc Haber]

On Tue, 4 Mar 2025 17:33:47 +0500, Andrey Rakhmatullin

Post by Andrey Rakhmatullin

Post by Blair Noctis

Post by Andreas Metzler
There is another downside to the BTS sending mails to uploaders. - There
is no simple unsubscribe, it would need a sourceful upload.

I wonder who would bother to add themself to Uploaders of a package,
but then refuse to read bugs related to it.

Packages accumulate Uploaders, because people who lose interest in a
package or in Debian as a whole rarely remove themselves.

That might change if they get mail.

Greetings
Marc

[Marc Haber]

Consider somebody being an active momeber of a larger team and leaving
it. He would continue to receive the mails sent uploaders. And the only
way to "unsubsribe" would be to make a (possibly huge) number of
sourceful uploads.

I think that most teams would be eager to help to remove you from
"Uploaders" in git, getting active with the next upload.

Greetings
Marc

[Andreas Metzler]

[...]

Post by Blair Noctis

Post by Andreas Metzler
There is another downside to the BTS sending mails to uploaders. - There
is no simple unsubscribe, it would need a sourceful upload.

I wonder who would bother to add themself to Uploaders of a package,
but then refuse to read bugs related to it.
Or if one really wants to,
they could set up a filter in their email client and/or server,
to filter out such emails.
This requires extra work,
just like your suggestion above.

Consider somebody being an active momeber of a larger team and leaving
it. He would continue to receive the mails sent uploaders. And the only
way to "unsubsribe" would be to make a (possibly huge) number of
sourceful uploads.

cu Andreas

[Andrey Rakhmatullin]

[...]

Post by Blair Noctis

Post by Andreas Metzler
There is another downside to the BTS sending mails to uploaders. - There
is no simple unsubscribe, it would need a sourceful upload.

I wonder who would bother to add themself to Uploaders of a package,
but then refuse to read bugs related to it.
Or if one really wants to,
they could set up a filter in their email client and/or server,
to filter out such emails.
This requires extra work,
just like your suggestion above.

Consider somebody being an active momeber of a larger team and leaving
it. He would continue to receive the mails sent uploaders. And the only
way to "unsubsribe" would be to make a (possibly huge) number of
sourceful uploads.

I agree with the Marc's reply to my earlier email that this is a feature.
Metadata should be uptodate. There is, of course, a question whether "the
current maintainers of a package" metadata field even makes sense to have
in binary or even source packages.

[Jonas Smedegaard]

Quoting Andreas Metzler (2025-03-04 17:44:33)

[...]

Post by Blair Noctis

Post by Andreas Metzler
There is another downside to the BTS sending mails to uploaders. - There
is no simple unsubscribe, it would need a sourceful upload.

I wonder who would bother to add themself to Uploaders of a package,
but then refuse to read bugs related to it.
Or if one really wants to,
they could set up a filter in their email client and/or server,
to filter out such emails.
This requires extra work,
just like your suggestion above.

Consider somebody being an active momeber of a larger team and leaving
it. He would continue to receive the mails sent uploaders. And the only
way to "unsubsribe" would be to make a (possibly huge) number of
sourceful uploads.

Regardless of team size, if someone steps down as uploader then that
change should be reflected in the control file.

- Jonas

[Jeremy Bícha]

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

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

[Don Armstrong]

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

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

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