hard to get from mp to per-revision diffs

poolie: if it deploys i will have poke at it for you
spiv: Thanks! The main thing for QA I think is to see that without the feature flag it doesn't break the branch merge proposal page (I'm sure it'll be fine),
spiv: and then if the feature flag is set (maybe just for canonifolk or beta-testers?) that the expanders exist and work on that page.

Fixed in stable r13481 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/13481>.

hloeung is helping me test this on qas.

It's a little complicated because the branch scanner and mp cron jobs do not regularly run and the mps from production are not available.

I created https://code.qastaging.launchpad.net/~mbp/bzr/doc-2.4 and a mp off it and I'm waiting to get the mp actually fully populated.

With the default (flag off) things look ok.

Haw added <https://code.qastaging.launchpad.net/+feature-changelog>

code.ajax_revision_diffs.enabled team:launchpad 1 on

And I see that in the footer comment, but I don't see any expanders yet.

OK, in <https://code.qastaging.launchpad.net/~mbp/bzr/doc-2.4/+merge/65290> I can see the diff appearing on the incremental revisions.

We ought to also add this feature on the initial mp revisions, and on the branch itself, but that can be done separately.

Also this makes it stick out to me how weirdly different the inital mp revisions are from those added after it's created.

Thanks for QAing that! Looking forward to seeing this on production.

This is now live and just waiting for the flag change to be ok'd to
turn it on for ~launchpad for the initial closed beta.

It's now switched on and working for ~launchpad.

So grepping the OOPS summaries since this was switched on I see only 1 OOPS that might be related to this, OOPS-2031CO104, and it's more likely that's just an IE6 glitch that we don't care about. (I looked for OOPSes involving /diff/ in their URL, as well as skimming reports matching OOPS-.*CB.)

So it seems this isn't causing any errors. Time to give this wider exposure? Or is there something else that should be done first?

there are at least two follow on bugs, though personally I don't think they need to block rollout to at least ~launchpad-beta:

bug 814696
bug 814697

The bug about it being very slow on LP branches is particularly
concerning to me - there is another bug that loggerhead does not have
a timeout mechanism; I think if we had one - and we will be adding one
- those requests would be timing out consistently, and its the absence
of that mechanism that means you're not seeing oopses.

I suggest looking at the service times in the apache log / loggerhead
logs instead - anything over 1 second is undesirable, over 5 seconds
is very worrying and 9 seconds would be a critical today, if we had
timeouts wired up for loggerhead.

For LP branches, the first request always times out, but after that it works fine.

bug 814696 and bug 814697 are now done, though bug 904070 (about handling private branches) is still open.

The current state of this is that the code is landed and live, but only for ~launchpad, and it does not work on private branches (bug 904070.) I would like to enable it generally, and leave it just not working for private branches, since they are a fairly minority case, the failure is fairly clean and having it on for most branches is an improvement in general utility.