Comment 7 for bug 492145
Revision history for this message
| Martin Pool (mbp) wrote Re: [Bug 492145] Re: email about updated mp diffs includes obsolete/misleading cover letter | #7 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
35a32c5
(Get the code!)
2009/12/8 Aaron Bentley <email address hidden>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Martin Pool wrote:
>> 2009/12/8 Aaron Bentley <email address hidden>:
>>> Ah, this is actually a review request email, and as such there's
>>> possible overlap with bug #307461.
>>
>> Maybe the "you have been subscribed"
>
> It doesn't say "you have been subscribed", it says "You have been
> requested to review..." There are no subscriptions on individual merge
> proposals, which is a design decision.
>
>> should say something like "...
>> which replaces the previous review xxxx"
>
> I suppose we could vary the message depending on whether you've
> previously been asked to review, e.g. "You have been requested AGAIN to
> review..."?
Sorry, "subscribe" was inaccurate. I meant distinguishing "you have
been requested to review" because ~bzr-core is asked to review all of
them vs "you personally have been requested to review", and also
distinguishing resubmitted from original mps.
> FWIW, there has been some discussion of making the cover letter an
> editable field like a bug description, and that would have allowed vila
> to update the cover letter as appropriate. Would that fix this bug?
Something like that.
So I think this bug is: when you are requested to review a mp, you are
always sent an email with the contents of the first message, even if
there has been extensive discussion and updates to the branch such
that the first message is no longer a good representation of what's
going on.
Bugs largely avoid this by having an editable summary and description.
If there was a separate cover letter field, we would need to work out
how that meshes with the intended commit message. Perhaps it should
be cast as being supplementary to the commit message and also empty.
Also we would need some view on the ordering of events when somebody
pushes an update to the branch: if you are going to send mail about
the update, perhaps it would be best to send it when both the cover
letter and the diff have been updated, but they are done separately.
Perhaps it's enough to send them separately, but with a short delay
(as in bugs?) to give them a chance to get into the same email.
--
Martin <http://