bug contacts should be able to unsubscribe from implicit subscriptions

Arguably the three examples you give aren't good ones, because they're actually dozens of separate bugs in a single bug report. (If they were a single bug, the diff that fixed the bug in one package would usually fix it in the others too, which is implausible since they're entirely different software.) However, there may be other cases -- if not now, then in the future -- where flamewars or long tedious discussions break out, and a project/package subscriber (or even the reporter) wants to unsubscribe from *that particular report*, without unsubscribing from others.

We used to have this feature, actually. It was called an "ignore subscription", which gives you an idea of how awkwardly we presented it. :-) We could present it much better now. In the subscriber list, unsubscribed implicit subscribers could have their name preceded by a cross graphic, while all other subscribers had their names preceded by a checkmark graphic. For yourself (and teams you were a member of), the graphic would instead be a checkbox that you could uncheck, regardless of whether your subscription was a direct or indirect one.

Please do. I'm sick of reading mail about java not working, because someone thought it was ubuntu-restricted-extras' problem, when it wasn't, and I have no way of stopping it.

I think it depends on your definition of a bug. if we could get this fixed, then we would have a good way to track issues, such as library transitions. It looks like the timeout problem that also affected large bugs has been fixed.

I think we are losing upstream because of this. It's not the first time I see an upstream who is subscribed to bugs in Ubuntu annoyed because he can't unsubscribe from a bug affecting thousand of products/packages.

So would be awesome to have this fixed :)

On 21/01/09 21:10, Emilio Pozuelo Monfort wrote:
> I think we are losing upstream because of this. It's not the first time
> I see an upstream who is subscribed to bugs in Ubuntu annoyed because he
> can't unsubscribe from a bug affecting thousand of products/packages.

Can you give any specific examples of upstreams that are affected by this?

> So would be awesome to have this fixed :)
>

I'm marking this as triaged since we have a good understanding of how we
want to fix it.

 status triaged

Graham Binns wrote:
> Can you give any specific examples of upstreams that are affected by
> this?

Sure. Many upstreams subscribe to bug mail of Ubuntu packages. That's quite good
(I guess I don't need to explain why).

Now, let's say upstream for package X is subscribed to bugs in X. A bug is
reported, affecting 50 packages, one of them being X. Then every subscriber to
that bug (including our upstream) starts to be flooded by mail from that report,
he wishes to unsubscribe from that report but he can't, and then he as to
consider whether to unsubscribe from bug mail completely, or to support the
flooding until it stops.

For example a Real Live example, just before I commented on this report:

21:57 < Atomo64> c'mon... at times I wish I had not subscribed to my packages
in launchpad, especially when I get notified about things like
https://bugs.launchpad.net/bugs/217908
21:58 < p2-mate> Atomo64: unsubscribe ?
22:03 < Atomo64> p2-mate: the thing is that there are some reportts that are
actually valuable, and I don't want to miss them

HTH,
Emilio

I also have an example. I lost 2 of the primary contributors to ~debichem specifically because of this bug. I talked to them and they said that was the sole reason they deactivated from the team. Note that they are also upstream/Debian developers.

In response to the previous couple of comments, I'm tagging this as an
upstream relations issue and subscribing Jorge Castro of the community team.

 tag ubuntu-upstream-relations
 subscribe jorge

This bug is coming up on it's first anniversary. Please just fix it. It
was a high priority MOTU bug too. I have unsubcribed from bugs for some
packages because of this.

 Sorry, but this is quite ridiculous. In good faith I subscribed to irssi in ubuntu too because I wanted to help fixing the problems both for Debian and Ubuntu in one go and to ease the workload of the MOTUs for the benefit of both our userbases - but currently I can all but just give in because of the perl 5.10 recompile bug: https://bugs.launchpad.net/bugs/230016

 I'm one of the "upstream authors/maintainers" you are losing, right here, right now. Sorry, and quite disappointed.

See also bug #482382 regarding the worst case seen so far (bug #429322).

What actually needs to be done to fix this? From the comments, this seems to be a particularly annoying bug. Maybe if there's some tips here, someone might be tempted to fix it now that we're open source.

I don't think there's currently an agreed solution to this problem (should this bug really be set to Incomplete?). One option is not sending notification for duplicates, since there's some anecdotal evidence that they are not actually that useful. Another solution would be to provide 'negative' subscriptions, that is, the ability to request that no further notifications be sent regarding a particular object (but that solution is quite involved).

The latter is certainly what I thought the bug was about. If it's not, I
can file another one as dupes have nothing to do with the problem I was
hoping this bug would solve.

I think there's a broad agreement that ignore subscriptions is a desirable feature, so if you or anyone wants to have a stab at implementing them let's do it. As always, grab one of us on IRC for a design/pre-implementation chat.

* Tom Berger <email address hidden> [2009-11-16 00:51:46 CET]:
> I don't think there's currently an agreed solution to this problem
> (should this bug really be set to Incomplete?). One option is not
> sending notification for duplicates, since there's some anecdotal
> evidence that they are not actually that useful.

 This is not what this bug is about. If this actually does also happen
then it should be tracked in a seperate bug (and indeed would be
additionally annoying).

> Another solution would be to provide 'negative' subscriptions, that
> is, the ability to request that no further notifications be sent
> regarding a particular object (but that solution is quite involved).

 This is exactly what this bug is about and which is extremely
inconvenient as has been lied out several times already, I thought.

 Thanks,
Rhonda

We (Rawstudio Team) have been added to Bug #502565 and we really don't care about it, but we have no way of removing ourself from getting notified upon updates and it's really annoying...any chance of a fix?

/Anders

Graham, is there anything going on with respect to it? Having it marked as "Triaged" for well over a year doesn't really look promising - setting back to confirmed.

This bug isn't currently being worked on, though it is on our radar as something that we want to fix in the coming year, along with a lot of other things to do with bug subscriptions.

There's no need to set it back to Confirmed however. A bug being "Triaged" means that a Launchpad developer has looked at the bug, understands its cause, and knows how it need to be fixed. I'm setting this bug back to Triaged accordingly.

With the proposed changes to projects and distros, owner can grant user and teams permission to view everything, which means explicit subscription is not needed for access.

        Hi!

* Curtis Hovey <email address hidden> [2010-09-28 19:50:53 CEST]:
> With the proposed changes to projects and distros, owner can grant user
> and teams permission to view everything, which means explicit
> subscription is not needed for access.

 I am uncertain what you mean by this. The bugreport isn't about
explicit subscriptions but being able to _un_subscribe from bugs with
*implicit* subscriptions through packages/team memberships and the
likes.

 Thanks,
Rhonda

Moving back to triaged since it's actually a more complex issue than I thought.

r12573 in stable (http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/12573) is part of this bug's fix.

Fixed in stable r12602 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/12602>.