[03:31] <blr> wgrant: are webhooks at a point now where I could look at building out a view perhaps?
[04:12] <wgrant> blr: Not at the moment -- hopefully later in the week. Is setbranch all done from your perspective/
[04:14] <blr> wgrant: yep, the cherry picked link name changes are here: https://code.launchpad.net/~blr/launchpad/project-configuration-rename/+merge/261918
[04:14] <blr> once that's landed, imagine it will be much easier to review the other branch
[04:15] <wgrant> blr: Oh, can you flip that out of WIP?
[04:15] <blr> wgrant: gah, sure thing
[04:16] <wgrant> One day things like this will be sensible.
[04:16] <wgrant> eg. bugs will say whether they're open or closed
[04:16] <wgrant> And MPs will do the same, except with an additional state that is neither.
[04:16] <wgrant> Rather than expecting everyone to know and notice the particular statuses...
[04:16] <blr> that sounds sensible
[04:19] <blr> can you think of anything that needs addressing atm? (otherwise I'll find some more bugs to poke at)
[04:27] <wgrant> blr: One thing we need is a ref picker.
[04:27] <wgrant> blr: For +register-merge, mostly.
[04:27] <wgrant> Currently you have to type the target ref manually.
[04:27] <wgrant> It's the most annoying bit about Git MPs atm.
[04:28] <wgrant> https://app.asana.com/0/29290342588691/37033052254451
[04:34] <blr> wgrant: great, will have a look after I tidy up this MP.
[04:39] <lifeless> asana?
[04:44] <wgrant> lifeless: Lightweight task tracking service.
[04:51] <lifeless> wgrant: using it for LP development?
[04:54] <wgrant> lifeless: Where it makes sense, yes.
[05:10] <lifeless> seems a little ironic ;)
[05:12] <wgrant> lifeless: No moreso than using kanban like in the old days.
[05:12] <wgrant> LP bugs is good for tracking some types of things.
[06:25] <wgrant> blr: Are you around to fix the broken test? If not, I'll do it.
[06:42] <blr> wgrant: back sorry
[06:42] <wgrant> blr: No worries.
[06:50] <blr> wgrant: https://code.launchpad.net/~blr/launchpad/project-configuration-rename/+merge/261930
[06:51] <wgrant> blr: Thanks.
[07:37] <blr> wgrant: buildbot happy, will get the other branch merged.
[20:45] <blr> morning
[20:47] <wgrant> Morning blr
[20:47] <wgrant> cjwatson: Do you believve the GitHostingClient regressions to all be fixed now?
[20:53] <blr> wgrant: did something blow up, or are you just up early? :/
[20:53] <wgrant> blr: Just an early meeting.
[20:54] <blr> ah good
[21:06] <cjwatson> wgrant: Yes - they weren't regressions (well, except from unmerged code) since they only affected the patch case, and I've confirmed that to be working now
[21:07] <wgrant> Oh, yeah.
[21:07] <wgrant> No empty responses yet.
[22:02]  * wgrant gets a lot of coffee and dives back into blr's setbranch
[22:04] <blr> wgrant: ah thanks
[22:04] <wgrant> blr: Thanks for cutting the irrelevant bits out of the diff.
[22:04] <wgrant> It's still 1700 lines, but that's a lot better than 2300 :)
[22:04] <blr> hopefully easier to deal with now
[22:04] <blr> yes :)
[22:05] <wgrant> And the changes are mostly to a few files rather than EVERYWHERE.
[22:05] <blr> in retrospect I should have made the renaming changes first... will try to think about decomposing branches before going down the rabbithole next time
[22:07] <blr> wgrant: when looking at it again yesterday, I did wonder if it needs an additional test for the setDefaultRepository case
[22:08] <wgrant> blr: It's often difficult to foresee quite how deep the rabbithole is.
[23:33] <blr> wgrant: just lodging a bug suggesting that the test factories should use the first available Person.name rather than throwing an exception - is that reasonable?
[23:37] <blr> introducing more randomness to the property is probably the only way to manage it without a db query
[23:39] <blr> wgrant: if you have any comments https://bugs.launchpad.net/launchpad/+bug/1465438
[23:39] <mup> Bug #1465438: Factories should ideally use first available Person.name <test-system> <Launchpad itself:Triaged> <https://launchpad.net/bugs/1465438>
[23:46] <wgrant> blr: It shouldn't cause a serious performance regression; NameAlreadyTaken is raised when getByName returns something, so it's already performing an extra query.
[23:47] <wgrant> blr: The login code uses generate_nick to create a unique name.
[23:48] <blr> wgrant: a minor annoyance. I'll make a note about generate_nick thanks
[23:48] <wgrant> Yeah, it's quite irritating, but usually only a problem in the harness rather than in tests.
[23:48] <wgrant> Could also include a timestamp in the generated names (it doesn't just affect Person), or possibly only do that outside tests.
[23:49] <wgrant> But tests shouldn't be depending on the specifics of the name generation, so always including something unique would probably be fine.
[23:49] <blr> wgrant: yep, that seemed like the least obtrusive way to improve it