Launchpad bazaar branch notification emails should include revision id

[Kristian Nielsen]

In Launchpad one can subscribe to email notifications for when new revisions are pushed to a bazaar branch.

The email includes information like this:

    X-Launchpad-Branch-Revision-Number: 2747
    revno: 2747

But the bazaar revision ids (revid:) are not included in the emails. This is a problem, as bazaar revision numbers are not stable, they can change anytime the branch is modified.

In particular, we use the notification emails to drive a Buildbot installation. But without the revision ids, the history gets confused whenever the revno: numbers change after a push.

More generally, there is no really reliable way to get from a notification email to the actual revision in a branch without
access to the revision ids.

Suggestion: include the revision ids in the notification emails, along with the revno: numbers.

[Jonathan Lange (jml)]

I was going to say that this fix is trivial, but it actually involves changing the parameters to a bunch of functions.

I don't have a clear picture of how the stack fits together, but here's what I've found:
  * IRevisionMailJobSource.create
  * RevisionMailJob.create
  * BranchMailer.forRevision
  * BranchMailer.__init__

and possibly others.

AIUI, these all would need to be changed to take the revision ID. Also, whatever is at the top of the stack (a scanner event?) would have to pass the revision ID in.

Not difficult per se, just quite a few places to change, and a bit of exploration to do.

[Aaron Bentley (abentley)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kristian Nielsen wrote:
> Public bug reported:
>
> In Launchpad one can subscribe to email notifications for when new
> revisions are pushed to a bazaar branch.
>
> The email includes information like this:
>
> X-Launchpad-Branch-Revision-Number: 2747
> revno: 2747
>
> But the bazaar revision ids (revid:) are not included in the emails.

One of the design goals of bzr is that revision-ids should not appear in
the UI. If you are really concerned, you can set the
append_revisions_only flag in the relevant branches.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqVJhMACgkQ0F+nu1YWqI2pAgCdHtI4kbe1j106L4iGdb4355L7
MP4An2vNmzMGTzWxI9WA2P4M+AXPwBfa
=0J4s
-----END PGP SIGNATURE-----

[Kristian Nielsen (knielsen)]

> One of the design goals of bzr is that revision-ids should not appear in
> the UI. If you are really concerned, you can set the
> append_revisions_only flag in the relevant branches.

We have append_revisions_only on main trees, but that means we cannot have it on topic branches that merge from main trees. With parallel development, _some_ tree must necessarily accept mutating revno:'s.

Anyway, thanks for taking time to explain. Design goal or no, I don't see how something like Buildbot can meaningfully keep history of past builds and revisions without having access to the revid:'s? But if that is really how bzr is meant to work I will have to see if there is some other way to solve the problem ...

[Jonathan Lange (jml)]

Does an email header _really_ count as UI? It seems like a border-line case to me.