request merge should send an email

Confirmed, I'd very much like to be notified when someone has proposed a merge to a branch that I own.

:-Dustin

I am currently getting email notifications when someone proposes merging to a branch that I own (or is owned by a team that I am a member of). This is great! It looks like I can respond to the merge proposal and my comments get listed as code review comments.

However, I'd like to request two additional bits of information in the notification email that would make the merge proposals even more useful:
1) Include the whiteboard info in the merge proposal notification email. Currently the only content in this email is the urls of the two branches involved in the merge - showing the whiteboard message would allow me to understand why the merge is being requested without having to flip over and load launchpad.

2) Include the diff of the merge, that is the changes that would be made if the merge was approved. This would allow me to do the code review right in my email client, responding to various sections of the diff and then sending the response off to launchpad.

There was the explicit design decision not to send implicit emails, but instead to implicitly subscribe the branch owner (although it has been argued that we should subscribe only the branch registrant), and that way the owner can unsubscribe if they really don't want to get emails. One of the fields that can be set for a branch subscription is the amount of code review email the subscriber wants.

Any subscriber that has asked to get code review email for a branch will get an email when the subscribed branch is either the source or target branch for a merge proposal.

The current line of thinking is that the best way to ensure that you get the emails is to subscribe to the trunk branch of the project (or the main branch that is being targetted), and specify that you want all code review emails.

Elliot:
  1) Being done, and should be in 2.1.9 (bug 242642)
  2) Also being looked at, but is dependant on some other email work we have in the pipeline. I expect this to be done before the end of this year. One implementation right now is to teach launchpad about merge directives. I'll leave the details to your imagination right now as things are in flux :-)

On Tue, Aug 19, 2008 at 9:07 AM, Tim Penhey <email address hidden> wrote:
> There was the explicit design decision not to send implicit emails, but
> instead to implicitly subscribe the branch owner (although it has been
> argued that we should subscribe only the branch registrant), and that
> way the owner can unsubscribe if they really don't want to get emails.
> One of the fields that can be set for a branch subscription is the
> amount of code review email the subscriber wants.
>

I haven't ever received email for someone creating a merge proposal
one of my branches. This makes the feature less useful to me, because
it means I have to keep checking all my trunks.

jml

On Tuesday 19 August 2008 11:43:17 Jonathan Lange wrote:
> On Tue, Aug 19, 2008 at 9:07 AM, Tim Penhey <email address hidden> wrote:
> > There was the explicit design decision not to send implicit emails, but
> > instead to implicitly subscribe the branch owner (although it has been
> > argued that we should subscribe only the branch registrant), and that
> > way the owner can unsubscribe if they really don't want to get emails.
> > One of the fields that can be set for a branch subscription is the
> > amount of code review email the subscriber wants.
>
> I haven't ever received email for someone creating a merge proposal
> one of my branches. This makes the feature less useful to me, because
> it means I have to keep checking all my trunks.

That is probably due to when we made this change, we didn't go and
create subscriptions for all existing branches. Branches created before
the change don't have the implicit subscribers, so you'd have to go and
subscribe to your own trunks.

Tim