[13:37] <mterry> Saviq: is there a way we could have CI run on MPs that are WIP?  (maybe with an opt-in or opt-out...)  I would find it helpful to have CI run the tests for me and make sure the MP is all-green before unleashing it on reviewers (I can run locally, but it's not always the same and takes some of my time to babysit them)
[14:20] <om26er> Hi! How far along are pointer friendly indicators ? Are they expected to appear anytime soon ?
[14:32] <cimi> om26er, hi, yeah they should happen soon https://bileto.ubuntu.com/#/ticket/2291
[14:50] <Saviq> mterry, it's just software, wonder if it's a common enough use case to warrant the added complexity?
[14:50] <Saviq> +but
[14:50] <Saviq> mterry, in any case, lp:jenkins-launchpad-plugin
[15:02] <tsdgeos> Saviq: mterry: why not doing what you did in https://code.launchpad.net/~mterry/unity8/slm-test/+merge/313546 ?
[15:02] <tsdgeos> i seems to have worked since noone reviewed that branch :D
[15:03] <mterry> tsdgeos: it still creates noise
[15:03] <tsdgeos> mterry: well, then you can just run the CI "manually", no?
[15:03] <tsdgeos> otoh that's also a bit cumbesrome
[15:03] <mterry> tsdgeos: not as user friendly yeah
[15:04] <mterry> This isn't a huge pain in my ass.  Just trying to streamline my flow and avoid situations where reviewers (you for example) wait for me to get green lights.  I guess I can run tests more locally but that's not as nice as CI doing it for me
[15:05] <tsdgeos> sure
[15:11] <Saviq> mterry, I think that's probably the most interesting thing - improving the unity8-ci job so that it takes just the MP link and finds all it needs itself
[15:11] <Saviq> instead of having to pass branch and MP link and revision...
[15:12] <Saviq> you can already pass only the branch, it will work, just not report anywhere (of course)
[15:13] <mterry> Saviq: oh that's part of it being user unfriendly.  But also a normal MP gives me an email from LP when it's done, automatically kicks off on a simple bzr push, I can see the history of the job runs in the MP, etc.
[15:14] <Saviq> mterry, sure, lp:j-l-p is the thing that's deciding which MPs to run CI for
[15:14] <mterry> I might poke at it, yah
[15:14] <Saviq> more important, IMO, is so it runs on top-approved MPs than on WiPs, but I suppose this might be easier
[15:15] <Saviq> mterry, as for "maybe opt-in or something", that would suggest LP should have a new status between WiP and NR
[15:15] <Saviq> not sure I'd go as far as that
[15:15] <Saviq> I'd probably just do --include-wip
[15:15] <Saviq> it only runs for branches owned by trusted people anyway
[15:16] <Saviq> there's not so many WiP ones
[15:16] <Saviq> and it's just a matter of adding a "Work in Progress" string to a list
[15:16] <Saviq> top-acked are a bit more tricky, because you want to un-ack them and make sure the top revision is what's approved
[15:17] <mterry> Saviq: maybe -- or you could opt in by setting Description to "ci-plz" or something hacky...
[15:17] <Saviq> oh and yeah, git ;)
[15:17] <mterry> But all CI could work too
[15:17] <mterry> I mean
[15:17] <mterry> All WIP could work too
[15:17] <Saviq> I'd be ok with that
[15:17] <Saviq> there are not so many of those
[15:18] <Saviq> and it'd be a per-project decision
[15:18] <tsdgeos> we actually have kind of a lot of WiP
[15:18] <tsdgeos> but almost noone commits to them
[15:18] <tsdgeos> so that's "fine"
[15:18] <mterry> If anyone complains about the extra churn, I'd also be happy if it just did WIP on mterry branches  :)
[15:20] <Saviq> tsdgeos, yeah that's what I meant, there's little movement on them
[15:21] <Saviq> when we turn this on is when things will be busy for a while, but it will settle down
[15:21] <Saviq> and most of them will probably die in conflicts to start with
[15:21] <tsdgeos> yep
[15:21] <tsdgeos> i wouldn't complain if we enable for trusted-WiP  either
[15:21] <tsdgeos> can enable it on a friday so all the busy stuff is done over the WE
[15:21]  * tsdgeos did a bit of french there
[17:07] <mterry> josharenson: so I looked at the arrangement branch a bit...  nothing jumped out at me as obviously wrong.  I tried to back up the branch to find where it went wrong, but Mir dependencies made that hard.  no insights yet
[17:08] <josharenson> mterry: I'm in the same place.. there is only 1 small thing I noticed
[17:08] <josharenson> mterry: I have all kinds of Keys.onPressed scattered through out the code
[17:09] <josharenson> mterry: and there was a weird thing with the app drawer... If I typed ~3 characters in the search bar, there were hundreds of key events triggered
[17:10] <mterry> huh
[17:10] <josharenson> mterry: which was suspicious... but I backed out the changes to the shell and the launcher and saw no improvement
[17:10] <josharenson> mterry: I even replaced the greeter with a blue rectangle and didn't see any change
[17:10] <mterry> huh
[18:03] <josharenson> mterry: Heres one for you... Log in (with a passwordless user since you can't type) and then lock the session... Greeter works perfectly afterwards.
[18:03]  * josharenson has an idea or two now...
[19:31] <mterry> josharenson: that's odd