[09:44] <cjwatson> wgrant: buildbot failure is yours rather than mine, I believe
[09:45] <wgrant> Bah
[09:45] <wgrant> Dodgy import.
[10:27] <cjwatson> wgrant: The unauthenticated-modifying-BMP thing seems to happen in various zopeless situations, judging from the test suite, and lp.code.subscribers.branchmergeproposal already had a similar check.  Do you want me to track down the exact causes of that and try to remove those guards?
[10:27] <wgrant> cjwatson: Sounds reasonable enough, feel free to leave it.
[10:29] <cjwatson> I'm not sure of the difference between user is None and isinstance(user, UnauthenticatedPrincipal).
[10:31] <wgrant> Indeed, I was surprised it was UnauthenticatedPrincipal rather than None.
[10:33] <cjwatson> It might only be in the test suite, due to login(ANONYMOUS) in TestCaseWithFactory.setUp.
[10:33] <wgrant> Does it rSP, or does it really login() in Zopeless?
[10:33] <wgrant> Or fire the events directly?
[10:34] <cjwatson> lazr.lifecycle does queryInteraction to get the user if you don't pass it one directly
[10:35] <cjwatson> And TCWF.setUp login()s regardless of layer
[10:35] <cjwatson> The event dispatch is just something like notify(ObjectModifiedEvent(proposal, snapshot, [])), no rSP involved
[10:36] <wgrant> Right, so it fires it directly.
[10:36] <wgrant> Anonymous code couldn't usually modify an MP to cause an event.
[10:56] <cjwatson> Oh, sorry, you mean the point where it enters MP editing.  In the cases I'm looking at it's just Zopeless, so things like merge detection.
[10:56] <cjwatson> Which does notify_modified(proposal, proposal.markAsMerged, merge_revno)
[11:28] <mpt> wgrant, hi, is there a current graph of your progress with Critical LP bugs over time? I remember there was one a couple of years ago, but no idea where it was
[11:28] <wgrant> mpt: http://webnumbr.com/launchpad-critical-bugs
[11:29] <mpt> brilliant, thanks
[11:32] <cjwatson> mutter non-zero-based axis
[11:33] <wgrant> https://lpstats.canonical.com/graphs/LPProjectCriticalBurndown/20101208/20151009/
[11:47] <StevenK> It has remained remarkably constant
[11:48] <wgrant> Most of the remaining bugs are pretty boring.
[11:48] <wgrant> There are one or two timeouts that occur more than a dozen times a day.
[11:48] <wgrant> New ones crop up and we slay them.
[11:58] <cjwatson> I'm a little surprised the timeout chunk didn't drop more with the new DB servers.  Maybe some of those never show up in practice any more.
[11:58] <wgrant> Most that were slow for DB reasons (other than perhaps bug edits) were death by a thousand queries or absolutely terrible queries.
[11:59] <wgrant> Not just a few bad queries.
[13:10]  * cjwatson runs into the tension between writing "... for which this ... builds" because that way people won't make bogus Victorian grammar complaints, or writing "... that this ... builds for" because the grammar is fictional but getting complaints anyway
[13:12] <wgrant> We've classically used the former, but the latter I have no problem with.
[19:54] <blr> morning