When we start dropping changesets from the autoland repo (bug 1288845), changesets will just disappear. In addition, descendant changesets will be rewritten and their SHA-1s will change. This has a few implications: * Downstream consumers of "backout" commits (like pulsebot) won't have a signal to key off of to know a commit was backed out * Automation, etc may keep chugging away at changesets that are obsoleted/rewritten My proposed mitigation to this is to publish a pulse feed of new obsolescence markers. This will be similar to the existing feed for "push" events. However, we need a different payload type to distinguish a push event (which has a corresponding pushlog entry) from obsolescence events, which don't necessary stem from pushes. Strictly speaking, we could potentially create pushlog records when obsolescence operations are performed. But I'm concerned about overloading the pushlog for this. Although I concede the pushlog being an audit log of changes to the server is desirable. I worry overhauling the pushlog code and all the consumers to recognize this new use case of pushlog would be a lot of work.
Pushed by email@example.com: https://hg.mozilla.org/hgcustom/version-control-tools/rev/d0c0ee7dbd15 vcsreplicator: send Pulse messages with obsolescence info
I've deployed this as "experimental" status. We now have a hgpushes/v2 exchange. I've documented the new message types at https://mozilla-version-control-tools.readthedocs.io/en/latest/hgmo/notifications.html. glandium: could you please look at the obsolete.1 message type and verify it has enough metadata for pulsebot to make IRC notifications and update bugs when changesets are dropped from the autoland repo? Also, if you have any nits on the data format or want to request more features, the data format for the "v2" exchange isn't frozen, so we can do anything at this juncture.
I /think/ that's good, but it would probably be better to actually implement and test it.