Proposal: Unsubscribe ~bzr from all code review mail

Max Bowsher _ at maxb.eu
Wed May 25 16:05:38 UTC 2011


>> On 5/25/2011 7:30 AM, Max Bowsher wrote:
>>> I would like to propose that ~bzr should be unsubscribed from all
>>> branches. It's easy enough to subscribe to branches that you are 
>>> actually interested in receiving mail about - and if there are
>>> commons subsets of branches that many people would want to
>>> subscribe to, let us create dedicated teams for them.

> On 5/25/2011 2:09 PM, Gordon Tyler wrote:
>> I have the same problem. I have ~1800 unread emails in my bzr code
>> review mail folder

On 25/05/11 14:55, John Arbash Meinel wrote:
> ^A m (select all, mark as read).
> 
> Given that you've already filtered them into folders, it doesn't sound
> that difficult.
>
> I understand the issue, my main concern is that as someone who does read
> all of that mail (at least 90% of them), it really isn't that easy to
> subscribe to everything. Mostly because newly created branches, bzr/2.3
> vs bzr/2.4, etc.
>
> Note that I think with structural subscriptions, you can manually
> disable subscrptions. (Subscribe yourself directly, and then say you
> don't want email.)
> 
> That may only work for bugs at the moment, but I imagine it will work
> for more things soon.
>
> The reason to put it on "unsubscribe if you don't want to see it", is
> that you will get mail that you don't want, and then you can go
> unsubscribe. If I "subscribe if you want it", *I* have to know that I'm
> *not* getting mail that I should be getting. Which is certainly much
> harder to prove.

Regarding client side actions: Right, it's not *that* difficult, but
it's still not ideal that many people have to construct client side
filtering to discard mail they don't want - if we solve the issue
centrally, it's better.

Regarding the need to subscribe to newly created branches: That's a fair
use-case, and the sort of thing I was thinking of when I suggested
creating a new team.

Regarding Launchpad's ability to opt out via structural subscriptions:
As you say, it only works for bugs right now - and even if that were
fixed, if you don't want to have to explicitly subscribe to all newly
created branches, I don't want to have to explicitly hunt down each
branch which might send me email and manually opt out.

I disagree that spamming people with all possible mail they might want
when they join ~bzr is a good way to help people. Instead, let us make
it easy to subscribe explicitly to the things that each person desires.
For community contributors, the mail that they "should" be getting is
the mail they decide they want. The situation may be different for
Canonical staff members, of course, but in that case let's shift those
subscriptions to an appropriately defined team.

So, how about this:

Create two new teams, ~bzr-codereview and ~bzr-core-codereview. Replace
~bzr and ~bzr-core branch subscriptions with those teams. People who do
want existing mail levels then have a single point to opt in, and people
who don't, can stop receiving unwanted mail.

Max.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/bazaar/attachments/20110525/6c2d7a7c/attachment-0001.pgp>


More information about the bazaar mailing list