[02:26] <StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/branch-use-information_type-redux/+merge/107150
[02:41] <wgrant>     Resurrect branch-use-information_type and fix all of the test failures.
[02:41] <wgrant> StevenK: Do you have a diff of just the last part?
[02:43] <StevenK> Hm, I could possibly construct one
[02:45] <wgrant> StevenK: Also, in branchChanged and the child bit of transitionToInformationType you're setting information_type directly.
[02:46] <StevenK> wgrant: http://pastebin.ubuntu.com/1004087/
[02:47] <wgrant> Version control systems are very good at this if you commit regularly :)
[02:48] <StevenK> Shhh
[02:56] <StevenK> wgrant: I don't like the idea of recursing into transitionToInformationType from transitionToInformationType.
[02:57] <wgrant> StevenK: In fact, I don't like the idea of recursion at all
[02:57] <wgrant> Drop it
[02:57] <wgrant> The use cases are very few.
[02:57] <wgrant> information_type is now only inherited to the branch that's doing the restacking.
[02:57] <wgrant> Changing information_type no longer propagates.
[02:58] <wgrant> The number of potential writes is unbounded, and I can't see why anybody would really want it.
[02:58] <wgrant> We saw this morning that all the transitively_private cases are cases where people have project misconfigurations that will soon no longer be possible
[02:59] <wgrant> And +sharing will soon say "You have 10 private branches, fool"
[02:59] <wgrant> s/private/public
[02:59] <wgrant> In the very rare case that it might happen.
[02:59] <wgrant> I don't see how it will happen, though.
[03:00] <wgrant> StevenK: So, drop the child code, and any tests that require it.
[03:01] <wgrant> StevenK: Still, the branchChanged information_type setting thing needs to be transitionToInformationType
[03:02] <wgrant> StevenK: This probably means adding a flag to transitionToInformationType that says "I actually know what I'm doing and really want this to happen; don't bother checking if the policies allow this branch to be private"
[03:04] <StevenK> wgrant: Right -- I don't mind that idea, a strict_checking=True argument to transitionToInformationType.
[03:06] <wgrant> I was thinking i_promise_i_know_what_i_am_doing, but that works too
[03:11] <StevenK> wgrant: For a further win, I think that means the factory can use transitionToInformationType as well
[03:12] <wgrant> StevenK: That would indeed be the case.
[03:12] <StevenK> But I will worry about that after lunch.
[03:12] <wgrant> Sounds like a plan.
[03:37] <bigjools> r15291 \o/
[03:41] <wgrant> Indeed
[03:50] <wallyworld_> wgrant: StevenK: it seems to me that FileBugInlineFormView is defined and used in some tests but is not hooked up anywhere and so is never used. am i right?
[03:51] <wgrant> wallyworld_: That seems to be correct.
[03:51] <wallyworld_> wgrant: well, i'm going to delete it then i think
[03:51] <wgrant> Probably back from the days when it was more AJAXy
[03:51] <wgrant> Indeed
[03:51] <wgrant> Kill
[03:52] <wgrant> Note that some of the tests may be the only tests of the base class' functionality.
[03:52]  * wallyworld_ gets out the BFG 9000
[03:52] <wgrant> That may be why it was kept.
[03:52] <wallyworld_> hmmm. perhaps. will look at that
[04:01] <StevenK> wgrant: http://pastebin.ubuntu.com/1004143/
[04:02] <wgrant> StevenK: Maybe s/strict_checking/verify_policy/, since that seems to be the only check that needs skipping
[04:02] <wgrant> You can then reword the factory like this:
[04:02] <wgrant> if private is not None:
[04:02] <wgrant>     information_type = blah
[04:02] <wgrant> if information_type is not None:
[04:03] <wgrant>     tTIT
[04:03] <wgrant> Rather than the nesting you have now
[04:07] <StevenK> wgrant: http://pastebin.ubuntu.com/1004148/
[04:09] <wgrant> StevenK: "Check if the new information type complies with the `IBranchNamespacePolicy`."
[04:09] <wgrant> parens on line 42 are redundant.
[04:10] <StevenK> wgrant: If True, check if ... or just what you have?
[04:10] <wgrant> I think just what I have, but it's subjective.
[04:10] <wgrant> On line 64 the flag should be named explicitly to avoid people copying the code badly.
[04:11] <wgrant> Same with 127
[04:11] <wgrant> Otherwise fine.
[04:11] <wgrant> As long as information_type isn't set manually anywhere else.
[04:12] <StevenK> wgrant: A bunch of tests do it
[04:12] <wgrant> They are evil, but don't really count.
[04:13] <wgrant> They can't break anything
[04:14] <StevenK> wgrant: http://pastebin.ubuntu.com/1004155/
[04:14] <wgrant> Hm
[04:15] <wgrant> Buildbot passed less than 5:40 after you reverted your branch
[04:15] <wgrant> Suspicious
[04:15] <wgrant> Elapsed5 hrs, 37 mins, 26 secs
[04:15] <StevenK> It was marked testfix, buildbot won't wait for those
[04:15] <wgrant> Even so, builds have been taking more than 6 hours lately
[04:15] <wgrant> I guess we have had some optimisations in the last couple of days.
[04:16] <wgrant> test 16776 tests 16776 passed
[04:16] <wgrant> So it's correct.
[04:16] <wgrant> (well, there's potentially 300 missing, but I don't know quite how buildbot counts)
[04:17] <StevenK> That buildbot pass should fix up the db-stable deployment report too
[04:17] <wgrant> Not until it's on prod, IIRC
[04:17] <wgrant> But I don't quite remember.
[04:18] <StevenK> wgrant: Anyway, you seem fairly happy with this branch, shall I commit and push?
[04:19] <wgrant> StevenK: Indeed, and I shall go over it with my Fine-Toothed Comb of Pedantry again.
[04:20] <wgrant> Total LoC delta for William Grant: -740. Churn: 25890
[04:20] <wgrant> Yay
[04:21] <lifeless> wgrant: ohlo ?
[04:21] <wgrant> cjwatson's thing
[04:21] <lifeless> oh, I haven't seen that
[04:21] <lifeless> linky ?
[04:21] <wgrant> It's in lp-dev-utils now
[04:21] <wgrant> Apparently
[04:21] <lifeless> I should pull that :P
[04:22] <lifeless> did he send mail about it ?
[04:22] <wgrant> It counts from the introduction of the new policy by default
[04:22] <wgrant> He didn't
[04:22] <wgrant> It was discussed only on IRC and in the MP AFAIK
[04:23] <lifeless> ah
[04:23] <lifeless> perhaps I don't get lp-dev-utils MPs
[04:23] <StevenK> wgrant: How do you get the churn?
[04:24] <wgrant> StevenK: I used the vim option
[04:24] <StevenK> Hah
[04:25] <StevenK> wgrant: MP diff updated
[04:39] <StevenK> wgrant: How goes the combing?
[04:40] <wgrant> StevenK: Sorry, got distracted
[04:40] <wgrant> Looking
[04:41] <wgrant> wallyworld_: In your sharing jobs MP, I think you left the old sharing_jobs.error_dir config key there
[04:41] <wgrant> You deleted the section header, but not the error_dir key
[04:42] <StevenK> wallyworld_: It's raining in Sydney today -- you may think of it as the tears of NSW supporters if you wish.
[04:46] <StevenK> wgrant: Stop getting distracted!
[04:59] <wgrant> StevenK: Looks reasonable.
[04:59] <StevenK> wgrant: Toss it at ec2?
[05:02] <wgrant> StevenK: I'd test rather than land, given what happened before, but yes.
[05:02] <StevenK> Haha
[05:02] <StevenK> Trust our test suite much?
[05:03] <wgrant> Test suite, sure
[05:03] <wgrant> Testrunner... nope
[05:47] <wallyworld_> StevenK: did you even watch the game?
[05:48] <StevenK> wallyworld_: Nope
[05:48] <wallyworld_> heathn
[05:48] <wallyworld_> wgrant: you sure i left that error dir key in there? the mp diff says it's gone
[05:49] <StevenK> wallyworld_: Why would I want to watch thugby?
[05:49] <wgrant> wallyworld_: You removed the setting, not the schema key.
[05:49] <wallyworld_> why not? it's a great game
[05:49] <wgrant> 154	-dbuser: sharing-jobs
[05:49] <wgrant> 155	-
[05:49] <wgrant> 156	# See [error_reports].
[05:49] <wgrant> 157	error_dir: none
[05:51] <wallyworld_> ah ok. tests still run. but will remove, thanks
[06:31] <wgrant> wallyworld_: How're you intending to land this series?
[06:31] <wgrant> wallyworld_: It seems like the early bits could be landed now.
[06:31] <wgrant> Rather than doing it all in a 10000 line diff
[06:31] <wallyworld_> i rather do the whole lot
[06:31] <wgrant> That's a really good way to ensure that bugs slip through.
[06:31] <wgrant> But we'll see :)
[06:32] <wallyworld_> the functionality is all very narrowly focused
[06:32] <wgrant> Well
[06:32] <wgrant> There are things there like magically making the (API-visible?) sharing service writable when the moment the triggers are disabled.
[06:33] <wallyworld_> that can happen after the landing and we have seen that everything is ok for a bit
[06:33] <wgrant> I mean it's not a sensible thing to happen ever.
[06:33] <wgrant> How do those things follow?
[06:34] <wallyworld_> hmm?
[06:35] <wgrant> I don't understand the logic around "triggers are disabled, so it's OK for everyone to write to grants whenever they want"
[06:35] <wallyworld_> i don't think those are connected wither
[06:36] <wgrant> https://code.launchpad.net/~wallyworld/launchpad/subscribe-grants-access-1000045/+merge/106278 line 182
[06:36] <wallyworld_> triggers disabled = turn on ff to manually keep subscriptions in line with access
[06:37] <wallyworld_> sorry, what's your point?
[06:37] <wallyworld_> we are replacing trigger code with model code
[06:37] <wgrant> The sharing service magically becomes writable when the triggers are disabled
[06:37] <wgrant> Rather than when writing is enabled.
[06:37] <wgrant> This sharing service is callable over the API
[06:37] <wallyworld_> only indirectly
[06:39] <wallyworld_> the sharing service needs to be able to write to do the job the triggers used to do
[06:48] <wgrant> The diff's ~6000 lines, and has a number of changes that I don't really understand, and dozens of conflicts that I can see. It's going to be very difficult to land it as a whole in any sensible fashion.
[06:57] <wallyworld_> each individual piece has tests which need to pass
[06:58] <wallyworld_> it's not really that complicated - the end result is two jobs which clean up subscriptions for inaccessible bugs, and optional code to grant access when someone is subscribed
[06:58] <wgrant> And turning that on implicitly turns on APGs, because it makes the sharing service writable.
[06:58] <wgrant> And other side-effects that I haven't noticed yet.
[06:59] <wallyworld_> so what's wrong with turning on APGs?
[06:59] <StevenK> branch-use-information_type-redux => devel  [FAILED]   (up for 1:53:05) i-37557451
[06:59] <StevenK> :-(
[06:59] <wgrant> They're a great way to spy.
[06:59] <wgrant> Because they're not shown on the bug page yet.
[06:59] <StevenK> At least I know its marked as failed correctly ...
[06:59] <wallyworld_> they are shown on the +sharing page
[06:59] <wallyworld_> and it's not a side effect if the behaviour is intended
[07:00] <wgrant> The behaviour is not intended./
[07:00] <wallyworld_> to me it is
[07:00] <wgrant> And +sharing is not accessible to many people.
[07:00] <wallyworld_> we are not allowed to change the bug ui
[07:00] <wallyworld_> that was agreed to afaiui
[07:01] <wallyworld_> so we cannot show apg on the bug page
[07:01] <wgrant> Anybody who agreed to not showing APGs on the bug UI was silly and shall be overridden
[07:01] <wallyworld_> who made you god?
[07:01] <wgrant> We *cannot not show them*
[07:01] <wgrant> That would make bug access entirely opaque.
[07:01] <wallyworld_> it was agreed to by the product team and curtis i think but i could be wrong
[07:01] <wgrant> It may have been agreed that we wouldn't need to show AAGs, because they require a subscription.
[07:02] <wgrant> That is perhaps a reasonable position to take, but there is some dissent.
[07:02] <wgrant> Not showing APGs is entirely unreasonable.
[07:02] <wallyworld_> do they have to be shown on the bug page? what about the pillar page?
[07:03] <wgrant> They should probably be on some publicly visible page on the pillar somewhere.
[07:03] <wgrant> But it's essential that the bug page not make it impossible to see who has access.
[07:03] <wallyworld_> that's what i thought we were going to do
[07:08] <adeuring> good morning
[07:12] <lifeless> stub: hi
[07:12] <lifeless> stub: catchup ?
[07:19] <stub> lifeless: sure.
[07:21] <lifeless> stub: skype ?
[07:22] <lifeless> stub: why you no answer :P
[07:23] <stub> sorry - downstairs stealing my mike back
[07:23] <lifeless> ah :)
[07:24] <stub> better?
[07:24] <stub> adjusting
[07:29] <lifeless> stub: epic issues?
[07:43] <stub> I was hearing you fine
[07:43] <stub> I can hear you
[07:48] <stub> dropped out
[07:49] <jelmer> moin
[08:14] <danilos> frankban, hi, it seems my branch hasn't landed even though it passed all the tests; perhaps pqm acting weird or something?
[08:15] <frankban> yes danilos :-( it should be fixed now, restarted the full land for your branch
[08:18] <danilos> frankban, ack, thanks (though, you can also do a direct pqm-submit when you don't want to wait for the full cycle: not a hurry with this one :)
[08:19] <frankban> yes I know danilos, but since it was a testrunner bug, i just wanted to try the whole process again
[08:20] <danilos> frankban, ok, sure thing, sorry for being annoying then :)
[08:21] <frankban> danilos: you are not annoying, I always appreciate suggestions on processes :-)
[08:34] <wgrant> frankban: You can just search for tracebacks in the subunit output to confirm a good run
[08:34] <wgrant> frankban: It still ran all the tests.
[08:37] <frankban> wgrant: you are right, thanks
[08:38] <wgrant> If it was a good run you should see the full 17000ish count in the ec2 mail.
[08:38] <wgrant> Without even going into the subunit stream.
[08:38] <wgrant> AFAIK it's only on error that the stream gets corrupted.
[08:45] <czajkowski> jam: jelmer vila could someone have a look at https://bugs.launchpad.net/launchpad/+bug/1003576
[08:45] <_mup_> Bug #1003576: Automatic translation exports not committing PO files <regression> <translations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1003576 >
[08:45] <jam> looking
[08:45] <czajkowski> jam: thanks
[08:45] <czajkowski> dpm ^^^^
[08:45] <jam> I'm guessing this is the "translations for Q are fairly stalled right now".
[08:45] <wgrant> It's probably unrelated.
[08:45] <wgrant> But jtv would know
[08:46] <jtv> ?
[08:46] <dpm> hi jam, this is about translations for projects not being committed, rather than translations for the distro
[08:52] <jam> dpm, czajkowski, so at this point, I don't really know how to dig into this further without just agreeing that it is a critical issue (user impacting), and it should go into the queue of ThingsThatShouldBeFixed
[08:53] <czajkowski> jtv: hola there seems to be a possible regression bug https://bugs.launchpad.net/launchpad/+bug/1003576
[08:53] <_mup_> Bug #1003576: Automatic translation exports not committing PO files <regression> <translations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1003576 >
[08:58] <jtv> czajkowski: I'm looking into it — my guess is it's probably just transient problems or old locks sticking around.
[08:58] <wgrant> Ah
[08:58] <czajkowski> jtv: cheers
[08:58] <wgrant> You know what
[08:58] <wgrant> I haven't had export cronspam for days
[08:58] <wgrant> I wonder if it was never reenabled after the attempted initialisation earlier in the week
[08:59] <wgrant> I bet they reenabled stuff on ackee/loganberry, but not crowberry
[08:59]  * wgrant checks.
[08:59] <wgrant> Yeah'
[08:59] <wgrant> gnuoy: Hi
[08:59] <gnuoy> wgrant, hi
[09:00] <wgrant> gnuoy: translations-export-to-branch.py is still disabled on codehost@crowberry due to RT#52815. The other disabled jobs were reenabled a couple of days ago, but that one was apparently forgotten.
[09:00] <_mup_> Bug #52815: logitech usb headset sound output dies after 1 minute <gst-plugins (Ubuntu):Invalid> < https://launchpad.net/bugs/52815 >
[09:00] <wgrant> Could you uncomment it, please?
[09:00] <jtv> czajkowski: mystery solved.  :)
[09:00] <gnuoy> ok course
[09:00] <gnuoy> s/ok/of/
[09:01] <wgrant> I shall also prepare an appropriate script-monitor invocation
[09:01] <wgrant> As it appears to lack one.
[09:01] <gnuoy> wgrant, done
[09:01] <czajkowski> jtv: magic :)
[09:02] <wgrant> gnuoy: Thanks.
[09:02] <czajkowski> jtv: cheers
[09:02] <wgrant> No point running it manually now -- it may well take more than an hour and get killed.
[09:02] <czajkowski> dpm: yer sorted :)
[09:02] <wgrant> But we could do a manual run in an hour if dpm thinks it's urgent.
[09:02] <jtv> wgrant: if this script is not run for too long, it may lose updates.
[09:03] <wgrant> It will automatically run in a little under 20 hours
[09:03] <wgrant> It has not run in 4 days
[09:03] <jtv> Enough to lose a day's worth of data.
[09:03] <jtv> If it hasn't run in 4 days, then it may have lost 2 or 3 days' worth of data.  Adding a day is not good.
[09:04] <dpm> wgrant, I agree with jtv, if possible, it'd be good to have a one-off run asap in addition to the next run in 20 hours
[09:04] <wgrant> Surely it uses a last update time, not hardcoding 24 hours which will never work?
[09:04] <jtv> Not 24 hours, but way back when it did hard-code some fixed time period.
[09:04]  * wgrant checks.
[09:05] <wgrant>         """Get date of last translations commit to `branch`, if any."""
[09:05] <wgrant> That looks encouraging
[09:06] <wgrant> Yeah, should be fine
[09:06] <wgrant> it uses the last translations commit - a fudge factior
[09:06] <wgrant> Otherwise I would have had to append the exporter to my list of things that really aren't very good ideas :)
[09:09] <wgrant> gnuoy: I propose https://pastebin.canonical.com/66679/
[09:09] <gnuoy> wgrant, seconded
[09:11] <gnuoy> wgrant, done
[09:12] <wgrant> gnuoy: Marvellous, thanks.
[09:12] <gnuoy> np
[09:12] <wgrant> dpm: The export script somehow missed out on our usual monitoring; that has now been rectified.
[09:13] <dpm> thanks a lot for your help wgrant, great to hear it's sorted now
[09:13] <dpm> and thanks czajkowski
[09:13] <dpm> and gnuoy :)
[09:13] <wgrant> We'll do a manual run right after fastdowntime.
[09:13] <dpm> when's fastdowntime?
[09:13] <wgrant> 47 minutes from now
[09:13] <czajkowski> 10am UTC every day
[09:13] <dpm> cool
[09:13] <wgrant> It normally takes about 25 minutes, I think, but it's got 4 days of stuff to do
[09:14] <wgrant> "It" being translations-export-to-branch
[09:14] <wgrant> fastdowntime will hopefully take about 67 seconds.
[09:15] <dpm> jtv, did your changes to fix translator credits and other stuff in Translations you were telling me the other day land?
[09:24] <dpm> hi could someone give some guidance to the guy willing to help fixing bug 869824? I think just a few comments in the bug report would already be helpful. Thanks!
[09:24] <_mup_> Bug #869824: Doing a search in the ddtp-ubuntu project's translations templates times out <ddtp> <nightmonkey> <search> <timeout> <Launchpad itself:Triaged> <Ubuntu Translations:Triaged> < https://launchpad.net/bugs/869824 >
[09:29] <jtv> dpm: I added a note.
[09:30] <wgrant> I'm trying with a trigram index
[09:30] <wgrant> Should help at least a bit.
[09:30] <wgrant> Will see in a few minutes
[09:30] <jtv> You're trying it right now?
[09:30] <wgrant> On dogfood, but yes.
[09:30] <wgrant> Indexes building
[09:30] <jtv> Ah, that explains.  :)
[09:31] <wgrant> Although the potranslation index is going to be maaaaassive
[09:31] <dpm> thanks jtv, glad to hear that the upgrade might help. Did you see the question above about the recent translations changes branch you mentioned a few days ago? ^
[09:31] <jtv> dpm: oh, sorry — phone.
[09:31] <jtv> Missed that.
[09:31] <jtv> Well the branch I was waiting for has finally rolled out.
[09:31] <jtv> The follow-up branches are now going through testing prior to landing.
[09:33] <nigelb> wgrant, StevenK - are you both purple mafia too?
[09:33] <wgrant> Yes
[09:33] <jtv> If only they could have asked Al Capone such a simple question.
[09:33] <nigelb> heh
[09:34] <nigelb> wgrant: Wasn't there some work to change the diff generation from cron to job queue? rabbit? Did that land?
[09:34] <nigelb> (or was that not purple)
[09:34] <dpm> jtv, cool. So once they've all landed, if I recall correctly, some of the things that we'll see are: translator-credits cleanup, translations done with message sharing enabled will be correctly committed, regardless of whether they were done in the distro or in the upstream project. Is that correct? Anything else?
[09:34] <wgrant> nigelb: The backend job stuff is currently being tested on staging.
[09:34] <wgrant> It's not purple.
[09:34] <nigelb> Ah. Deryck's team?
[09:35] <wgrant> Yes
[09:35] <nigelb> Aha.
[09:35] <czajkowski> Orange :)
[09:35] <jtv> dpm: I'm not sure what you mean with committing of translations, but the *credits* will start fixing themselves.
[09:35] <wgrant> dpm: It won't affect the comitting
[09:35] <wgrant> dpm: That requires additional work
[09:36] <jtv> The credits for Ubuntu and upstream will be more or less identical.
[09:36] <dpm> ok, understood, thanks wgrant and jtv
[09:39] <StevenK> nigelb: Purple *Assassins*
[09:39] <nigelb> StevenK: Right. Sorry. Hey, I suggested the name. I think.
[09:39] <bigjools> Purple Headed Monsters
[09:40] <StevenK> nigelb: Maybe a variation of it.
[09:40] <wgrant> jtv: Bah
[09:40] <wgrant> jtv: My plan is foiled
[09:40] <nigelb> bigjools++
[09:40] <wgrant> # CREATE INDEX temp_pomsgid ON pomsgid USING gist (msgid gist_trgm_ops);
[09:40] <wgrant> ERROR:  index row requires 8436 bytes, maximum size is 8191
[09:40] <nigelb> Any of you other than rob headed to kiwipycon?
[09:41] <jtv> wgrant: no toast?
[09:41] <wgrant> jtv: Not for an index, I guess.
[09:41] <jtv> :(
[09:41] <wgrant> jtv: We probably have to use full FTI
[09:41] <wgrant> Rather than an ILIKE
[09:41] <nigelb> StevenK: I think I gave it a different colour. Someone else picked the colour.
[09:42] <bigjools> we should become the Rampant Reds
[09:42] <jtv> Oh please no
[09:42] <nigelb> Rowdie Reds
[09:42] <jtv> wgrant: annoyingly, what we have works just great for everything else.  We've been hoping for ddtp-ubuntu to be split up a bit more, but…
[09:42] <StevenK> nigelb: We were Teal, until wgrant, sinzui and I revolted.
[09:42] <czajkowski> wgrant: there is downtime today at 20:00 UTC
[09:43] <bigjools> I now have the Monty Python scene in my head ... "Welease Woger!"
[09:43] <wgrant> czajkowski: There is
[09:43] <wgrant> jtv: I'm surprised it works
[09:43] <wgrant> jtv: Given the whole seq scan thing
[09:43] <czajkowski> wgrant: there is
[09:43] <nigelb> StevenK: Haha
[09:43] <bigjools> StevenK: you were already revolting
[09:43] <wgrant> jtv: I guess every other template has few enough messages that it can just check them all...
[09:43] <StevenK> bigjools: You must have taught me well, then.
[09:44] <jtv> wgrant: Exactly.
[09:44] <nigelb> bigjools: Where in Australia are you settled?
[09:44] <StevenK> nigelb: In wallyworld_'s lap.
[09:44] <mgz> the great barrier reef
[09:44] <nigelb> lololol
[09:44] <nigelb> I didn't realize this question would involve *hilarious* answers :)
[09:44] <wallyworld_> i otlerate him for now
[09:44] <wgrant> jtv: Also, that query is terrifying, btw
[09:44] <bigjools> wgrant: your children will be next
[09:45] <bigjools> err
[09:45] <bigjools> wallyworld_: : your children will be next
[09:45] <StevenK> Hahaha
[09:45] <wgrant> That could be a while
[09:45] <nigelb> best. tabfail. ever.
[09:45] <mgz> ehehe
[09:45] <jtv> wgrant: I don't recall it off the top of my head, mercifully
[09:45] <bigjools> I hate irc
[09:45] <wallyworld_> bigjools: next for what?
[09:45] <jtv> Ice cream!
[09:45] <wgrant> jtv: It is 94 lines in length.
[09:45] <bigjools> wallyworld_: you've heard the Manic Street Preachers?
[09:45]  * wallyworld_ shakes his head
[09:46] <bigjools> you probably have but don't remember
[09:46] <bigjools> I'll play some next time you're round
[09:46] <wallyworld_> ok
[09:46] <bigjools> one of their tracks is called Australia :)
[09:46] <jtv> Why wait?  Turn up the volume a bit more.
[09:46] <bigjools> ha
[09:46] <wallyworld_> so long as it's not more van halen
[09:46] <bigjools> HEATHEN
[09:46] <nigelb> bigjools: Anyway, so you're in Sydney? Melbourne?
[09:47] <bigjools> Bris
[09:47] <nigelb> Ah.
[09:47] <wgrant> ie. nowhere
[09:47] <bigjools> I went to Melbournce once
[09:47] <bigjools> that was enough
[09:47] <jtv> Grrr why can't I connect to anything?
[09:47] <bigjools> and Melbourne too
[09:49] <nigelb> I should be touching one of Sydney, Melbourne, or Brisbane on my way.
[11:27] <danilos> lifeless, hi, is there something I need to do to get db-stable r11610 deployed?
[11:31] <czajkowski> danilos: wrong timezone for him
[11:31] <danilos> czajkowski, he's lifeless, there's no wrong timezone for him ;)
[11:36] <cjwatson> danilos: Wait.  See https://wiki.canonical.com/InformationInfrastructure/OSA/LaunchpadProductionStatus
[11:36] <nigelb> danilos: valid point there :)
[11:38] <danilos> cjwatson, thanks, but I've out of the process for a while, do you know if DB r11611 will also include r11610? or should I get a separate request up there
[11:38] <danilos> cjwatson, btw, are you rotating in LP, or just hacking on it (not so) randomly? :)
[11:39] <cjwatson> danilos: It means "everything up to r11611" (the rest are just merges and such)
[11:40] <danilos> cjwatson, cool, thanks, so it's not cherrypicking, great
[11:40] <wgrant> We haven't cherrypicked in a long time.
[11:40] <cjwatson> danilos: Not rotating as such, but probably the majority of my scheduled work for this cycle involves improvements that Ubuntu Engineering needs in Launchpad
[11:40] <danilos> cjwatson, right, cool
[11:40] <cjwatson> danilos: So same kind of deal as the Linaro work items work AIUI
[11:40] <danilos> cjwatson, yeah
[11:41] <danilos> cjwatson, btw, while we are on the topic, do you know if ubuntu is planning to do any migration of their old workitems? I'd like to get rid of the migration script to help our LOC cause :)
[11:42] <cjwatson> danilos: I was under the general impression we weren't (and I'm not sure I see the point myself), but I'm not authoritative for that
[11:42] <cjwatson> AFAIK we're using the new work items field for all quantal work and no longer care about pre-quantal work items
[11:43] <cjwatson> I thought Kate was the contact for verifying that
[11:43] <danilos> cjwatson, she was, I haven't seen her on IRC for a few days though
[11:43] <cjwatson> she's on IRC right now ...
[11:43] <czajkowski> cjwatson: thoguht it was going to be raised to stakeholders mrevell may know more about that
[11:43] <cjwatson> well, logged in I mean
[11:44] <cjwatson> czajkowski: isn't Kate our stakeholders contact, or one of them?
[11:45] <czajkowski> cjwatson: aye she is but in case there was further discussion needed maybe danilos should mail and disucss it there?
[11:46] <danilos> czajkowski, that's in process (mrevell is handling that), so I was just trying to see if I can get a speedier response :)
[11:46] <czajkowski> danilos: not something I'm sure that can/will rushed  :)
[11:47] <danilos> czajkowski, what, a simple confirmation of the previous agreement/decision? I think it can :P
[11:47] <cjwatson> Seems like it should be a no-brainer from our side, TBH, but I don't know if there was any contention or if this is just being careful
[13:30] <jamestunnicliffe> Hi sinzui, thanks for the review (https://code.launchpad.net/~dooferlad/launchpad/upcomingwork-expand-all/+merge/107083). Should I put the JS in lp/app/javascript? It just feels a bit specific to 1 page to put in a general directory.
[13:31] <sinzui> jamestunnicliffe,  lp/blueprints/javascript/workitems.js maybe.
[13:31] <jamestunnicliffe> sinzui: OK, will do.
[14:10] <jam> mgz, vila, jelmer, gmb: Just to confirm, June 25th - June 29th works for everyone, right? I'm starting to fill in all the forms about where and when
[14:10] <jam> I wouldn't book tickets just yet, but I would block out your calendars
[14:10] <mgz> should be, will double-double check now
[14:11] <mgz> jam: might be best to do these kind of arrangements in #launchpad-kitchen on the internal irc server
[14:11] <jam> I didn't feel that a sprint was particularly private... but we could
[14:11] <jam> I would have arranged in it #bzr in the past
[14:12] <vila> jam: should be good here too
[14:12] <vila> meh, I meant the dates, not the channel, I agree -kitchen sounds like the best place ;)
[14:13] <jam> though I would have to actually join #launchpad-kitchen to discuss anything there :)
[14:13] <mgz> it's less privateness and more relevence :)
[14:14] <mgz> those dates are indeed good for me.
[14:18] <gmb> jam, Yes, 25th-29th is fine.
[14:18] <jam> gmb: good to hear
[14:36] <barry> lifeless: any chance you might be around?
[14:41] <jelmer> jam: hi
[14:42] <czajkowski> sinzui: jpds raised https://bugs.launchpad.net/launchpad/+bug/1003972
[14:42] <mgz> jelmer: he's just gone out to mini-swimming, presumably will be back a little later
[14:43] <jelmer> mgz: aha
[14:43] <czajkowski> sinzui: not sure that's a regression
[14:43] <czajkowski> or planned
[14:43] <mgz> jelmer: free for me to mumble at you briefly?
[14:44] <wgrant> czajkowski: dupe
[14:44] <jelmer> mgz: ish, 
[14:44] <jelmer> mgz: I'm on leave today, at a conference at the momwnt
[14:45] <mgz> ah... hadn't gathered. can wait then. you back tomorrow or off then too?
[14:46] <mgz> no, off both by the staffing email.
[14:46] <mgz> will bother you next week then.
[14:46] <jelmer> sure :)
[14:49] <jpds> wgrant: Shouldn't you be in bed? ;)
[14:49] <sinzui> czajkowski, as you can see I discovered the bug yesterday. It is a regression
[14:49] <wgrant> Probably
[14:49] <mgz> can't a man hack from bed?
[14:50] <wgrant> Have to revert bad changes to the help wiki first
[14:51] <wgrant> And now I should sleep, before I discover again that someone is wrong on the Internet.
[14:56] <czajkowski> what bad changes on the help wiki
[14:56] <czajkowski> sinzui: okie dokie
[16:21] <sinzui> jcsackett, Do you have time to review https://code.launchpad.net/~sinzui/launchpad/licenses-modified/+merge/107229
[16:22] <jcsackett> sinzui: certainly, i'll take a look in just a moment.
[16:22] <sinzui> thank you
[16:34] <jcsackett> sinzui: r=me.
[16:50] <rick_h_> hah, love jcsackett's branch name "simplify-everything"
[16:50] <rick_h_> was expecting a bit more though :P
[17:56] <lifeless> barry: hi
[17:57] <lifeless> danilos: hi, we don't cherry pick db patches, ever :) - we deploy one and only one; and the policyandprocess wiki page should cover it all
[17:57] <barry> lifeless: hi.  wanted to talk to you about py3 support for lazr.restfulclient and lazr.authentication
[17:58] <lifeless> danilos: I'm thinking to make the FDT process the second checkmarkable test process
[18:03] <lifeless> barry: go on :P
[18:05] <barry> lifeless: you're probably seeing the internal discussion over on #c but, other than py3 compatible oauth, i need to get rid of wsgi_intercept, which afaict is only used in the package's test cases.  i am not going to port w_i because several of *its* dependencies need to be ported.  for l.rc and l.a, i plan to just steal the few bits of w_i it needs for the test suite
[18:06] <barry> lifeless: e.g. lazr/restfulclient/testing/intercept.py
[18:06] <barry> lifeless: tho it sucks that i'll have to cargo cult that into l.a too
[18:11] <lifeless> barry: why not do the thing right?
[18:11] <lifeless> barry: it sounds like you're adding technical debt for us to pay the next cycle over
[18:12] <lifeless> barry: its hard to get excited about that :(
[18:12] <barry> lifeless: the problem is wsgi_intercept has *a lot* of stuff we don't use, plus several dependencies which themselves would have to get ported.  i want to avoid a multiweek detour right now
[18:13] <barry> lifeless: i could always disable the test suites <wink>
[18:13] <lifeless> barry: I understand it has that; but you did an rdepends on the build graph before planning to push for 3-only this cycle
[18:13] <lifeless> so I don't understand how it can be surprising or concerning
[18:13] <barry> lifeless: not so surprising.  the debian package doesn't build-dep on it because its tests don't run during package build :(
[18:14] <lifeless> so from the debian package perspective, there is no issue
[18:14] <barry> lifeless: well, i can't just do the upstream port and cross my fingers
[18:14] <lifeless> right? All you need to do is make changes to the package which a) don't break python2 and b) let it work in python3 on the CD
[18:15] <barry> lifeless: how will i know it works on py3?  i can test that it installs, but can't run the upstream test suite.  doesn't give me lots of confidence
[18:15] <lifeless> barry: you could, but thats orthogonal; how can I help you ?
[18:16] <barry> lifeless: i want to know whether you'd accept a branch that removes the w_i dependency, and pulls in just the small bits needed for the l.rc and l.a test suites
[18:16] <lifeless> barry: It makes me very uncomfortable
[18:16] <lifeless> barry: our track record with undoing such short-term actions is deplorable
[18:17] <lifeless> barry: Unless there is a committed project that guarantees the time to come back and set it right, it would just be adding maintenance costs
[18:17] <barry> lifeless: i can appreciate that.  so which is the bigger evil, given that porting w_i's stack is simply not feasible right now
[18:17] <lifeless> barry: have you tried porting it ?
[18:18] <lifeless> (what makes it not feasible)
[18:18] <barry> lifeless: i have looked at it, yes.  to run *its* test suite, means porting mechanize, mechanoid, zope.testbrowser, and maybe one or two others
[18:19] <barry> webunit
[18:19] <barry> Paste
[18:19] <barry> and that's not even chasing *their* dependencies
[18:20] <cjwatson> Would it be possible to build a py3 wsgi_intercept that doesn't support intercepting so many web testing frameworks?
[18:20] <cjwatson> I mean, mechanize, mechanoid, zope.testbrowser are needed because wsgi_intercept has explicit support for intercepting them; but we wouldn't need that for lazr.restfulclient etc. if they aren't relying on those frameworks themselves
[18:20] <cjwatson> So it could be a reduced-capability port
[18:21] <barry> cjwatson: yes, that might be possible.  just the parts that lazr.* care about are about 400 lines
[18:22] <barry> that code is honestly not that interesting.
[18:23] <barry> cjwatson, lifeless: lazr.httplib2_intercept? :)
[18:23] <cjwatson> Well, what I meant wasn't to fork wsgi_intercept into lazr, but to keep it being wsgi_intercept, just less featureful - but irrelevantly so for lazr
[18:24] <cjwatson> I don't think lazr.httplib2_intercept would meet lifeless' concerns, as I read them above :)
[18:43] <barry> cjwatson: could be feasible if i don't bother the w_i test suite under py3
[18:55] <lifeless> barry: hi, sorry
[18:55] <lifeless> I blame iwlwifi
[18:55] <lifeless> again
[18:55] <lifeless> + NM getting horrifically confused
[18:56] <lifeless> I have a call to prep for, so I can't chat more now
[18:56] <lifeless> 06:24 < cjwatson> I don't think lazr.httplib2_intercept would meet lifeless' concerns, as I read them above :)
[18:56] <lifeless> was the last I saw before network fail
[18:59] <barry> lifeless: no worries.  i'll look at a partial port of w_i but won't bother with its test suite, which would be infeasible right right now
[18:59] <lifeless> my key criteria are:
[18:59] <lifeless>  - do not want increased maint burden for LP team
[19:00] <lifeless>  - do not want trouble maintaining the python 2 versions in existing stable releases
[19:00] <lifeless>    (such as they need it)
[19:00] <lifeless> Beyond that, go to town.
[19:21] <jcsackett> sinzui: re bug 1003482, which project did you notice it on?
[19:21] <_mup_> Bug #1003482: privacy banner is not shown by default when reporting a bug <disclosure> <regression> <ui> <Launchpad itself:Triaged by jcsackett> < https://launchpad.net/bugs/1003482 >
[20:12] <abentley> jcsackett: Could you please review https://code.launchpad.net/~abentley/launchpad/short-celrerybeat-transactions/+merge/107277 ?
[20:24] <jcsackett> abentley: looking now.
[20:24] <abentley> jcsackett: thanks.
[20:24] <jcsackett> abentley: that's quite an LoC credit.
[20:26] <abentley> jcsackett: Thanks!  It was mostly deleting the create-merge-proposal job.
[20:29] <jcsackett> abentley: i can see where that would benefit your credit a lot, yes. :-P
[20:30] <abentley> jcsackett: There was a certain sacrifice involved; I originally wrote create-merge-proposal-job.
[20:30] <jcsackett> abentley: they say for good writing, you have to murder your darlings. i suppose coding is much the same. :-P
[20:31] <jcsackett> abentley: also, r=me. looks fine.
[20:32] <abentley> jcsackett: thanks.
[20:33] <jcsackett> sinzui: can i get you to look at two MPs for me? https://code.launchpad.net/~jcsackett/launchpad/simplify-everything/+merge/107240 and https://code.launchpad.net/~jcsackett/launchpad/privacy-banner-with-better-info/+merge/107244
[20:33] <sinzui> okay
[20:34] <jcsackett> the first of those fixes the private-by-default banner issue too.
[20:34] <jcsackett> apparently my simplifications fixed the regression.
[20:34] <sinzui> \o/
[20:35] <jcsackett> yeah, it's always nice when that happens. :-)
[20:41] <cjwatson> Maybe I should write a variant of (or option for) loc-contributions that ranks all contributors by how much credit they have.
[20:41] <cjwatson> If you want to make progress on something, turn it into a competition :-)
[20:45] <sinzui> jcsackett, simplify-everything is r=me when you fix the open span tag
[20:46] <jcsackett> sinzui: ah! thanks. my eyes kept slipping right over that.
[20:47] <sinzui> jcsackett, I have a gedit plugin that auto completed markup. When I pretended to create a near the end, it suggested that I close a span
[20:48] <jcsackett> hm. may need to ping some vim experts and see if i can get the same sort of thing setup in my editor.
[20:48] <sinzui> jcsackett, r=me for the other branch.
[20:48] <jcsackett> sinzui: thanks!
[20:49] <sinzui> jcsackett, my plugin is python, the rules for choosing what can be completed might be adaptable to vim
[20:49] <rick_h_> jcsackett: xmledit is a great autocompleting plugin for tags. won't check for valid though
[20:50] <jcsackett> rick_h_: you can bolt html linting into vim though, can't you?
[20:50] <rick_h_> I'm looking, I've never lint'd my html. I so rarely have issues with it. Usually it comes up in browser or page testing I guess
[20:51] <rick_h_> the trouble is that in any templating, code can so make linting go boom!
[20:51] <sinzui> jcsackett, read markup generator: http://bazaar.launchpad.net/~sinzui/gdp/trunk/view/head:/plugins/gdp/complete.py
[20:51] <rick_h_> but I do use xmledit for auto closing opened tags as I go along which is nice
[20:51] <jcsackett> yeah, with vim-python and some elbow grease that can probably be made into a vim plugin.
[20:52] <jcsackett> rick_h_: that would be good. i'll take a look at it.
[20:52] <sinzui> jcsackett, Edwin wrote instructions to integrate pocket-lint to vim
[20:52] <jcsackett> rick_h_: though i may take a stab at sinzui's plugin. i've been wanting an excuse to play with the black magic of vim plugin creation.
[20:52] <rick_h_> jcsackett: yea, there's a book  in github that's "learn vimscript the hard way"
[20:52] <jcsackett> sinzui: hrm. i remember that; i even had that working at one point. i wonder why it stopped.
[20:53] <jcsackett> or rather, when i removed it, given i have no plugin for it now.
[20:53] <sinzui> jcsackett, https://dev.launchpad.net/UltimateVimPythonSetup
[20:54] <rick_h_> jcsackett: http://perlbuzz.com/2012/03/new-htmllint-beta-validates-html-entities.html
[20:54]  * jcsackett bookmarks both links
[21:16] <barry> lifeless: how's this for awesomeness.  wsgi_intercept can't even work with the python3 version of httplib2
[21:25] <lifeless> gary_poster: bzr switch -b myname
[21:27] <lifeless> flacoste: do you have a couple of minutes; I have a couple of backlogged things to chat about ?
[23:48]  * StevenK stabs the branch security adapter
[23:50] <StevenK> wgrant: I'm seeing something very strange. test_branchlookup.TestGetByLPPath.test_private_branch is creating a branch that is USERDATA, but if I print the information_type in IBranch.visibleByUser it's PUBLIC
[23:50] <wgrant> StevenK: Check DB logs to see what's happening, perhaps.
[23:50] <wgrant> It's often the easiest way
[23:52] <wgrant> Or show me the test :)
[23:52] <StevenK>         branch = self.factory.makeAnyBranch(private=True)
[23:52] <StevenK>         path = removeSecurityProxy(branch).unique_name
[23:52] <StevenK>         self.assertRaises(
[23:52] <StevenK>             NoSuchBranch, self.branch_lookup.getByLPPath, path)
[23:57] <wgrant> StevenK: Is it possibly calling it early?
[23:58] <wgrant> And caching?
[23:58] <wgrant> Before transitionToInformationType is called