requesting review by a team should send mail to that team

On Fri, Oct 10, 2008 at 1:03 PM, Paul Hummer <email address hidden> wrote:
> Public bug reported:
>
> In merge proposal code, this XXX comment is found:
>
> "If the reviewer is a team, don't send email. This is to stop the abuse
> of a user spamming all members of a team by requesting them to review a
> (possibly unrelated) branch. Ideally we'd come up with a better
> solution, but I can't think of one yet. In all other places we are
> emailing subscribers directly rather than people that haven't
> subscribed."

I don't see why this is any worse than a team being subscribed to get
all bug mail for a product?

--
Martin <http://launchpad.net/~mbp/>

On Fri, Oct 10, 2008 at 1:13 PM, Martin Pool <email address hidden> wrote:
> I don't see why this is any worse than a team being subscribed to get
> all bug mail for a product?
>

It's a serious issue for the distro, who have branches owned by very,
very large teams. With luck, better branch support for source packages
will make the problem magically disappear. Until then, this current,
bandaid approach will keep a lot of users happy.

jml

See also bug 493902

Apparently 493902 is a dupe of this - there is some confusion about the different kind of person:mp relationships, which Aaron will try to explain separately.

For me the crucial case is: when I request a team to review an mp, it should send mail to that team. To me it is obvious that if the person is "requesting" the review, they want an actual request to end up with the team member.

Perhaps the case of very large teams could be handled by distinguishing the default reviewer (maybe set to None?) from the owner?

Other description:

As a patch author, i want the bzr windows developers (~bzr-windows) to review my patch and tell me if they see any issues, so i can avoid committing something that breaks win32. They're not subscribed to any branches by default.

When the user clicks "request a review" I think they can reasonably expect that this will actually request a view from the other party. This means the members of the requested team should be notified that a review is wanted.

See also bug 281056, about teams not getting reviews by default for branches they own. But it's a different case: that's about subscriptions whereas this is about review requests.

There is a possible risk of accidental or malicious spam by randomly subscribing large teams to noisy reviews, but that's already possible with bugs and doesn't(?) seem to be a large problem in practice.

In the spirit of not losing any possibly-related information:

There's a thread on the ubuntu-distributed-devel list called:

  "FYI: ubuntu-devel thread about merge proposals"
  https://lists.ubuntu.com/archives/ubuntu-distributed-devel/2009-December/000164.html

started by James Westby, that's related to the question of what happens when the user requests a review. The first message in that thread is, as its subject implies, basically a pointer to this *other* thread on ubuntu-devel:

  https://lists.ubuntu.com/archives/ubuntu-devel/2009-December/029694.html

which is also by James; he describes it as being "about who the default reviewer should be for Ubuntu merge proposals".

Both threads may have relevant discussion.

During QA found that the request review email was going to the entire team, but no other email for the proposal was.

Found the line that needs fixing, fix coming soon.