[00:23] <StevenK> wallyworld_, wgrant: https://code.launchpad.net/~stevenk/launchpad/fix-branch-subscribe-open-team/+merge/109960
[00:25] <bigjools> yay, spammers are harvesting email addresses from LP
[00:25] <bigjools> how?
[00:25] <bigjools> ah wait - pgp keys.  bastards.
[00:42] <StevenK> wgrant: So, DB patch, since I can't have breakfast. :-/
[00:42] <wallyworld_> StevenK: you still want the cancel_url set all the time
[00:43] <StevenK> wallyworld_: Right.
[00:44] <wgrant> StevenK: The bugtaskflat cache is ([policies], [grantees])
[00:44] <wgrant> StevenK: The branch cache can be (policy, [grantees])
[00:46] <StevenK> wgrant: In which case the subselect from APA just dies?
[00:47] <StevenK> wallyworld_: http://pastebin.ubuntu.com/1038217/
[00:49] <wgrant> StevenK: It still exists, but it only returns a single value, not an array.
[00:51] <wallyworld_> StevenK: i'd consider self.next_url = canonical_url(...) in the init() and in the one place where needed, set it to None
[00:51] <StevenK> wgrant: Oh, SELECT INTO _access_policy FROM (SELECT ...
[00:52] <wgrant> +        SELECT COALESCE(array_agg(policy), ARRAY[]::integer[])
[00:52] <wgrant> +            INTO _access_policies
[00:52] <wgrant> ->
[00:52] <wgrant> "SELECT policy INTO _access_policy
[00:54] <StevenK> wgrant: Could we fix the comment too? Since now we're on 9.1
[00:56] <StevenK> wallyworld_: Ah, I can't set it directly in the function, it breaks.
[00:57] <wallyworld_> which bit?
[00:57] <StevenK> wallyworld_: My test blows up with something about can't set next_url directly
[00:58] <wallyworld_> self.next_url is set in many other places
[00:58] <wgrant> That view probably has it as a property.
[00:59] <StevenK> It does
[00:59] <wgrant> Then that's obviously not going to work.
[00:59] <wallyworld_> the diff showed the property being removed
[01:00] <wgrant> StevenK: This should work, rather than the subquery madness: SELECT COALESCE(array_agg(policy ORDER BY policy)) FROM accesspolicyartifact WHERE artifact = 5;
[01:01] <wgrant> Good way to make sure everyone's upgraded to 9.1, too.
[01:06] <StevenK> wgrant: http://pastebin.ubuntu.com/1038229/
[01:07] <wgrant> StevenK: 227 is useless
[01:07] <wgrant> It doesn't do anything,
[01:08] <StevenK> wgrant: But that's what you said? :-)
[01:08] <wgrant> That's the SQL query.
[01:08] <wgrant> It's clearly not a useful PL/pgSQL statement.
[01:08] <wgrant> Since it doesn't put the value anywhere.
[01:09] <wgrant> StevenK: An alternative may be to have a general function which returns the arrays for a given artifact.
[01:10] <wgrant> BugTaskFlat can use them directly, but Branch can just extract the first policy
[01:10] <wgrant> Also, brb.
[01:15] <lifeless> wgrant: lp:~lifeless/squid/3.1-ext-tag
[01:15] <lifeless> bigjools: what about it ?
[01:16] <bigjools> lifeless: expiring librarian files - doesn't seem to be mentioned apart from an oblique reference in process-death-row changes
[01:16] <bigjools> make it explicit
[01:20] <lifeless> bigjools: do we gc the files two different ways?
[01:26] <bigjools> lifeless: what files? :)
[01:26] <bigjools> there's two lots of files at present
[01:27] <bigjools> and reaped separately
[01:27] <bigjools> death-row deletes the archive's files and the expiration script deletes the librarian files
[01:27] <bigjools> both to a different schedule
[01:27] <lifeless> where deleting a librarian file == unreferencing it ?
[01:28] <bigjools> right
[01:28] <bigjools> actually
[01:28] <bigjools> we set the date for deletion
[01:28] <lifeless> I believe pdr does that
[01:28] <bigjools> they both do
[01:28] <lifeless> or at least, what wgrant wrote claims it is what does it
[01:29] <lifeless> bigjools: when would one set it vs the other ?
[01:29] <bigjools> the expiration script deletes the librarian files something like 7 days later
[01:29] <bigjools> it gives people a chance to recover old files after they get auto-superseded from disk
[01:30] <lifeless> why don't we just set a 7 day later deletion date?
[01:31] <bigjools> because it affects quotas
[01:31] <bigjools> whereas the librarian doesn't
[01:31] <wgrant> bigjools, lifeless: Three phases: publisher sets SPPH.scheduleddeletiondate; p-d-r deletes from on-disk archive and sets SPPH.dateremoved; e-a-f sets LFA expiry to now
[01:31] <bigjools> wgrant: WFM
[01:31] <wgrant> But e-a-f excludes things with dateremoved within the last week
[01:31] <bigjools> but make it explicit in the wiki page
[01:31] <wgrant> It'd better work for you, since I was describing the current process :)
[01:32] <bigjools> given that I know the current process rather well that seems redundant
[01:32] <wgrant> lifeless doesn't.
[01:32] <wgrant> Well, didn't.
[01:32] <bigjools> which is why I was just explaining it ;)
[01:32] <wgrant> So, DisklessArchives doesn't affect expiry, since p-d-r will continue to set dateremoved.
[01:32] <wgrant> Or a p-d-r equivalent.
[01:33] <wgrant> dateremoved still exists -- it's probably used to determine whether a file is still visible or not.
[01:33] <wgrant> Since we can't just rely on publication state.
[01:33] <bigjools> presumably the proxy will serve 404s for dateremoved files?
[01:33] <wgrant> Precisely.
[01:33] <wgrant> The rewriter will fail the request.
[01:33] <bigjools> I think that's wrong
[01:33] <wgrant> Why?
[01:34] <bigjools> actually, scratch that
[01:34] <bigjools> it's fine
[01:34] <wgrant> It's correct, so it had better not be wrong :)
[01:34] <bigjools> the coffee kicked in and I remembered that the UI has librarian links :)
[01:34] <wgrant> So it doesn't affect expiry at all. I should probably have mentioned that.
[01:34] <bigjools> yeah, make it explicit
[01:35] <wgrant> (although if jml and james_w want to implement my e-a-f rewrite proposal they are welcome to :P)
[01:35] <bigjools> how do we currently work out quotas, is it adding up PUBLISHED files?
[01:35] <wgrant> No.
[01:35] <wgrant> datepublished IS NOT NULL AND dateremoved IS NOT NULL, or something like that.
[01:35] <lifeless> nasty horrible timingout query
[01:35]  * wgrant checks.
[01:35] <lifeless> hits the LFC IIRC.
[01:35] <wgrant> It's possible that datepublished isn't checked.
[01:35] <wgrant> But dateremoved is.
[01:36] <bigjools> ok
[01:36] <wgrant> lifeless: Of course; only LFC has the size.
[01:36] <bigjools> yes it checks LFC of course
[01:36] <bigjools> :)
[01:36] <lifeless> this might be something to dernorm as part of the project; solve quota performance
[01:36] <wgrant> It just checks dateremoved IS NOT NULL
[01:36] <lifeless> just a random though
[01:37] <wgrant> lifeless: On the contrary, if you're going to suggest that I'll add it to the out of scope section :)
[01:37] <wgrant> It's completely irrelevant.
[01:37] <bigjools> focus!
[01:38] <wallyworld> StevenK: just for you https://code.launchpad.net/~wallyworld/launchpad/bug-javascript-1011611/+merge/109966
[01:38] <wgrant> lifeless: Your lock has expired -- are you still writing?
[01:39] <lifeless> yes, sec
[01:45] <StevenK> wallyworld: r=me with one comment
[01:46] <wallyworld> StevenK: thanks
[01:47] <lifeless> wgrant: all done btw
[01:47] <wgrant> lifeless: Thanks.
[01:48] <wallyworld> StevenK: i've responded
[02:00] <lifeless> wgrant: so, 3.2 is in an interesting state just now; trunk has some acl breakage,w hich alex thinks he has fixed, but...
[02:00] <lifeless> there are folk running 3.2 in prod
[02:01] <lifeless> basically we'd need to validate it does what we want fairly carefully, so I think 3.1+patches is probably the way to go. I've backported the ext-tag support already for this.
[02:01] <wgrant> Hmmm
[02:01] <wgrant> Agreed, the ext_tag stuff looked fairly uninvasive.
[02:01] <wgrant> But I haven't seen your patch
[02:01] <wgrant> So I may not have seen everything.
[02:01] <lifeless> see the wiki page, tis all linked up
[02:30] <wgrant> StevenK: How goes the DB patch?
[02:31] <StevenK> wgrant: http://pastebin.ubuntu.com/1038289/
[02:32] <StevenK> I've been distracted trying to figure out how to disable next_url when it's a property
[02:32] <wgrant> StevenK: Make it not a property.
[02:32] <StevenK> wgrant: Zope will deal either way?
[02:33] <wgrant> Confused.
[02:33] <wgrant> Zope doesn't know it's a property.
[02:33] <wgrant> It's a property.
[02:35] <StevenK> wgrant: Zope will call it properly if it isn't a property?
[02:35] <wgrant> Make it an attribute.
[02:35] <wgrant> It doesn't need to be a method or property if you're going to set it explicitly.
[02:35] <wgrant> (it doesn't need to be, and it can't bd)
[02:36] <StevenK> wgrant: next_url = canonical_url(context) ?
[02:38] <wgrant> Right:
[02:38] <wgrant> if all_is_good:
[02:38] <wgrant>    self.next_url = canonical_url(context)
[02:39] <StevenK> wgrant: Not that easy.
[02:39] <StevenK> next_url is set in _BranchSubscriptionView, which the three subscription views subclass off
[02:59] <StevenK> Right, Zope does not love next_url if it's not a property
[03:00] <wgrant> What is "not a property"?
[03:00] <wgrant> It doesn't require it to be a property.
[03:00] <StevenK> wgrant: The function is not decorated with @property
[03:00] <wgrant> Well yes.
[03:00] <wgrant> Making it a method isn't going to change anything, apart from breaking the interface.
[03:01] <StevenK> Oh, it fixes the case where you're subscribing an open team nicely. It just breaks everything else. :-)
[03:01] <wgrant> Erm.
[03:01] <wgrant> What?
[03:01] <wgrant> How does it fix that?
[03:01] <StevenK> Because I can then just set self.next_url = None
[03:02] <wgrant> Ah.
[03:02] <wgrant> No.
[03:44] <wgrant> Mmmm, postgres 9.1
[03:44] <wgrant> So nice.
[03:44] <wgrant> GIN, column triggers, ordered aggregates...
[03:57] <wgrant> StevenK: http://paste.ubuntu.com/1038383/ or so
[03:58] <lifeless> -sonly
[03:59] <StevenK> wgrant: Hahah, 12-6, not 16-6 :-P
[03:59] <wgrant> StevenK: 12-6 is before BugTaskFlat was created :)
[03:59] <wgrant> So it doesn't work back then.
[03:59] <wgrant> Has to be after 16-0.
[03:59] <wgrant> lifeless: sonly?
[03:59] <StevenK> wgrant: Really?
[03:59] <wgrant> StevenK: It'll work on prod and staging.
[03:59] <wgrant> But not in make schema.
[03:59] <StevenK> Oh, of course, the patches will be applied in order
[03:59] <wgrant> Because make schema applies in numerical order.
[04:00] <StevenK> Yeah, just realised
[04:00] <lifeless> wgrant: -slony
[04:00] <wgrant> Ah
[04:00] <wgrant> Right
[04:00] <StevenK> I guess lifeless means no slony for 9.1
[04:00] <wgrant> Eventually.
[04:00] <StevenK> 10 second FDT sounds good
[04:04] <StevenK> wgrant: So I get the trigger on information_type changes on branch, is there another entry point I'm missing?
[04:06] <wgrant> StevenK: accessartifact_flatten_bug possibly wants to be renamed to reflect the fact that it now does branches too -- it's an INSERT OR UPDATE OR DELETE trigger on AAG and APA, so it handles the other two entrypoints.
[04:07] <StevenK> Right.
[04:07] <StevenK> accessartifact_update_artifacts ?
[04:08] <wgrant> Or accessartifact_denorm_to_artifacts, or something like that.
[04:08] <StevenK> I like that, let's do that.
[04:09] <StevenK> I have to DROP the trigger, I can't just replace which function it calls?
[04:12] <wgrant> Right, you'll need to drop the trig and func and recreate them with the new names.
[04:12] <StevenK> Yup
[04:12] <StevenK> And the comment
[04:13] <StevenK> There are four PERFORM accessartifact_flatten_bug in 16-0, do they need to change too?
[04:14] <wgrant> Oh right, there's an extra layer of indirection.
[04:14] <wgrant> Don't need to recreate the trigger.
[04:14] <wgrant> Just rename accessartifact_flatten_bug and replace its name in the trigger func
[04:15] <wgrant> Bah, but the trigger func is called accessartifact_maintain_bugtaskflat_trig
[04:15] <wgrant> So
[04:15] <wgrant> Drop trigger
[04:15] <wgrant> Drop accessartifact_maintain_bugtaskflat_trig
[04:15] <wgrant> So needs renaming.
[04:15] <wgrant> Drop accessartifact_flatten_bug
[04:15] <wgrant> Recreate the three with new names.
[04:43] <StevenK> wgrant: http://pastebin.ubuntu.com/1038425/
[04:51] <wgrant> StevenK: Pretty good. We can probably dump some of the SECURITY DEFINERs now, though.
[04:51] <wgrant> The internal functions shouldn't have them.
[04:51] <StevenK> So accessartifact_maintain_denorm_to_artifacts_trig can lose it, at least.
[04:52] <wgrant> branch_denorm_access, bug_flatten_access and bug_build_access_cache are probably the only ones that need it.
[04:52] <wgrant> All the other functions either do nothing interesting or are internal.
[04:52] <wgrant> Can possibly even do without bug_build_access_cache.
[04:52] <wgrant> Since the only other place that is called is the main bugtaskflat function.
[04:52] <wgrant> Which is itself a definer.
[04:53] <wgrant> StevenK: Do you know what SECURITY DEFINER does? :)
[04:53] <StevenK> wgrant: Nope, I was trusting your judgement.
[04:53] <wgrant> StevenK: It's setuid.
[04:53] <StevenK> Oh, argh.
[04:53] <wgrant> It causes the function to execute as the role that created it.
[04:54] <wgrant> Rather than the role that is executing it.
[04:54] <StevenK> Right, so the less functions that have it, the better.
[04:54] <wgrant> It's handy to put it everywhere for testing. And it's not a huge issue in our DB, since all the users are pretty much trustworthy.
[04:54] <wgrant> But yes, should be minimised.
[04:55] <wgrant> StevenK: Functions without SECURITY DEFINER also don't need the custom search_path.
[04:55] <wgrant> (same as you don't let a setuid binary execute things from PATH)
[04:56] <StevenK> wgrant: Is the converse also true?
[04:56] <StevenK> Do functions with SECURITY DEFINER need SET search_path = ... ?
[04:59] <wgrant> StevenK: Yes.
[05:00] <wgrant> Since names without an explicit schema (ie. everything in all of our DB functions) use the search_path.
[05:03] <StevenK> wgrant: http://pastebin.ubuntu.com/1038442/
[05:05] <wgrant> StevenK: CREATE TRIGGER accesspolicyartifact_maintain_denorm_to_artifacts_trigger
[05:05] <wgrant> That "maintain_" probably shouldn't be there
[05:05] <wgrant> Ditto in the second trigger.
[05:07] <wgrant> StevenK: I'd drop the SECURITY DEFINER from bug_build_access_cache
[05:07] <StevenK> wgrant: bug_build_access_cache was in your list of three that need it :-)
[05:07] <wgrant>     LANGUAGE plpgsql SET search_path = public AS $$
[05:07] <wgrant> That search_path can die.
[05:07] <wgrant> 14:52:40 < wgrant> Can possibly even do without bug_build_access_cache.
[05:07] <wgrant> 14:52:50 < wgrant> Since the only other place that is called is the main bugtaskflat function.
[05:07] <wgrant> 14:52:59 < wgrant> Which is itself a definer.
[05:09] <StevenK> wgrant: http://pastebin.ubuntu.com/1038447/
[05:20] <wgrant> StevenK: Plausible.
[05:28] <StevenK> wallyworld: Where's your branch that drops use of branch.explicitly_private and friend up to?
[05:28] <lifeless> wgrant: basic_fake_auth - 3.2 helper, don't need your python bit; another backport from 3.2 / build as separate package.
[05:29] <StevenK> wgrant: Shall I push up the DB patch, or do you want to ponder a bit more?
[05:29] <wgrant> StevenK: Push it up.
[05:29] <wgrant> StevenK: Well
[05:29] <wgrant> StevenK: First check that it works.
[05:30] <StevenK> wgrant: make schema works
[05:30] <wgrant> That doesn't mean much :)
[05:30] <wgrant> lifeless: Huh
[05:30] <wgrant> lifeless: Indeed, rather handy.
[05:31] <wgrant> http://wiki.squid-cache.org/ConfigExamples/Authenticate/MultipleSources describes a fair bit of what I discovered on Friday.
[05:31] <wgrant> It seems.
[05:36] <StevenK> wgrant: test_bug_mirror_access_triggers passes, still doesn't mean much? :-)
[05:37] <lifeless> wgrant: yeah, shocking, we have docs
[05:39] <wgrant> lifeless: I wouldn't really call that docs.
[05:40] <wgrant> StevenK: I'd check it works for branches too.
[05:40] <wgrant> StevenK: in psql
[05:47] <StevenK> wgrant: http://pastebin.ubuntu.com/1038476/
[05:48] <wgrant> StevenK: Check the toggling information_type toggles access_grants between {7} and NULL
[05:50] <StevenK> wgrant: http://pastebin.ubuntu.com/1038480/
[05:50] <wgrant> Marvellous.
[05:51] <StevenK> wgrant: Happy to check APA too, just not sure what policy should be.
[05:51] <wgrant> Anything.
[05:51] <wgrant> Anything at all.
[05:51] <wallyworld> StevenK: it's merged
[05:51] <wgrant> Deployed too, isn't it?
[05:52] <wallyworld> probably
[05:53] <wgrant> If it was deployed yesterday, rerun the usual information_type vs transitively_private consistency checks on prod, and drop the columns from code entirely.
[05:53] <StevenK> wallyworld: Do you want to handle that?
[05:53] <StevenK> Or shall I?
[05:54] <wallyworld> StevenK: i've got a few branches on the go, so feel free to take it. i thought you wanted to be the one to drop the columns etc?
[05:54] <StevenK> wgrant: http://pastebin.ubuntu.com/1038483/ -- not sure if that's what usually happens.
[05:54] <StevenK> wallyworld: Yes, where drop the columns is ALTER TABLE branch DROP COLUMN :-)
[05:55] <wgrant> StevenK: bug
[05:55] <wgrant> StevenK: Or you're mis-testing.
[05:55] <wgrant> Or my code is crap.
[05:56] <StevenK> wgrant: I'm happy to accept that I'm mis-testing.
[05:59] <StevenK> wgrant: How do I check?
[06:00] <wgrant> It's unfortunately not your fault, I don't think.
[06:00] <StevenK> Anything I can fix in 16-6?
[06:00] <wgrant> It's a bug in 16-6, so I hope it's fixable there, indeed.
[06:00] <StevenK> Ah. Can I have a clue? :-)
[06:00] <wgrant> Not until I do.
[06:01] <StevenK> I'll quickly put together a branch that drops *_private from the branch model.
[06:01] <wgrant> Great.
[06:02] <wgrant> lalala i am stupid
[06:02] <wgrant> Well
[06:02] <wgrant> lalalal postgres is visual basic
[06:03] <wgrant> (its array indices are based at 1, not 0)
[06:03] <wgrant> StevenK: Does that tell you how to fix it? :)
[06:03] <StevenK> Bwahaha
[06:03] <StevenK> One character bug
[06:05]  * wgrant fixes two timeouts.
[06:06] <StevenK> Hm, this could be difficult to rip out.
[06:06] <wgrant> Howso?
[06:06] <wgrant> Should be delet
[06:06] <wgrant> delete
[06:06] <wgrant> delete
[06:06] <wgrant> delete
[06:06] <wgrant> commit
[06:06] <wgrant> push
[06:06] <wgrant> bzr pqm-submit
[06:06] <StevenK> Given the branch browser code uses copy_field(IBranch['explicitly_private'])
[06:07] <StevenK> And one test still uses transitively_private, so wallyworld fails.
[06:07] <wgrant> Oh.
[06:07] <wallyworld> StevenK: i told you about that one on the call the other day
[06:07] <wgrant> wallyworld's branch didn't turn them into properties?
[06:07] <wgrant> SO the columns are still being read :(
[06:07] <wgrant> Fixing that is top priority and pretty trivial.
[06:08] <StevenK> Right.
[06:08] <wgrant> Only after that's deployed to appservers can we stop writing to the columns.
[06:08] <StevenK> Yeah
[06:08] <wallyworld> StevenK: i thought your next branch would be the one to drop them from the model code
[06:08] <StevenK> wgrant: Give me a few minutes and I'll throw up a branch.
[06:09]  * StevenK blinks, just having re-read that sentence.
[06:09] <wallyworld> hence i left that one behind since it can be done at the same time
[06:09] <StevenK> wallyworld: As wgrant says, we can't. They need to depend fully on information_type under the covers.
[06:09] <wallyworld> but the one remaining case is just some bug text view
[06:09] <wallyworld> which is not really used
[06:10] <wgrant> Plus the API :)
[06:10] <wallyworld> which i thought would be done when the class properties were dropped
[06:11] <wallyworld> i basically changed all the sql queries to use unfo type
[06:11] <wgrant> wallyworld: There's a race there.
[06:11] <wgrant> We need to stop reading before or at the same time as we stop writing.
[06:11] <wgrant> But deploys aren't atomic and isolated.
[06:12] <wgrant> So the read removal needs to be done in an earlier deploy.
[06:12] <wallyworld> sure
[06:12] <wallyworld> that's what i though StevenK was doing next
[06:12] <wallyworld> since he expressed an interest in doing the remainign bits
[06:15] <StevenK> I think lib/lp/code/model/tests/test_branch_privacy_triggers.py will fail with this change.
[06:15] <wgrant> It will.
[06:15] <StevenK> Nuke from orbit?
[06:16] <wgrant> Ideally replace with something that tests the new ones :)
[06:17] <StevenK> wgrant: Oh, sorry, I don't mean the branch that adds 16-6, I mean the branch that replaces explicitly_private and transitively_private with properties.
[06:18] <wgrant> StevenK: Hm?
[06:20] <StevenK> wgrant: http://pastebin.ubuntu.com/1038507/
[06:20] <wgrant> StevenK: You need to preseve the cols, just under different names.
[06:21] <StevenK> But nothing reads them anymore
[06:21] <wgrant> Not after that diff is deployed, no.
[06:21] <StevenK> Bug._private was for Storm's benefit
[06:22] <wgrant> But as I said above, we need to keep setting the DB columns until everything has stopped reading them.
[06:22] <wgrant> Now, if you try to stop both reading and writing in the one deploy, you're breaking things.
[06:22] <wgrant> Since one appserver will have stopped writing them while others are still reading them.
[06:22] <wgrant> == leak
[06:23] <StevenK> Ah.
[06:23] <StevenK> Curses.
[06:24] <wgrant> I have that effect on people.
[06:24] <StevenK> wgrant: http://pastebin.ubuntu.com/1038511/
[06:26] <StevenK> wgrant: And 16-6 psql test: http://pastebin.ubuntu.com/1038516/
[06:30] <wgrant> +    # These can die after the UI is dropped.
[06:30] <wgrant> I forget -- do we care about API?
[06:30] <wgrant> StevenK: That looks unbroken indeed.
[06:31] <StevenK> transitively_private is not exported, so can die.
[06:31] <StevenK> explicitly_private is exported
[06:31] <StevenK> As is private
[06:31] <StevenK> Because a non-duplicated interface is a bad one.
[06:31] <wgrant> explicitly_private is private
[06:32] <StevenK> wgrant: They're both on the interface. Seperately.
[06:33] <wgrant> Ah
[06:37] <wgrant> Erm
[06:37] <wgrant> Storm, what are you doing.
[06:38] <wgrant> Bad Storm.
[06:52] <StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/branch-privacy-properties/+merge/109987
[07:01] <StevenK> wgrant: Can haz review so I can do stuff while ec2 munches on it?
[07:02] <wgrant> StevenK: Done, with comment.
[07:49] <adeuring> good morning
[07:59] <rvba> Hi frankban, are we not on review duty today?
[07:59] <frankban> rvba: yes we are.
[08:00] <rvba> frankban: ;)
[08:53] <jml> benji: thanks for adding that readme :)
[09:34] <cjwatson> benji: Isn't it a bit odd that logs is still in .bzrignore?  (And also logs/README.txt via the logs/* entry.)
[09:37] <benji> cjwatson: yea it is a bit odd; I'll remove the directory itself.  I wonder how to ignore the non-README contents of the directory though
[09:41] <jml> benji: one (crappy) way, rename README to _README and ignore [A-Za-z]*
[09:44] <adeuring> stub: do you know the reason why ftq('aaa.bbb') returns the tsquery 'aaa' & 'bbb' | 'aaabbb'? Can't we simply drop this logic?
[09:46] <stub> adeuring: We can certainly drop and/or change the logic. Nobody has been able to really articulate what a search is actually supposed to do beyond 'be like google, but with substring matching' in the past.
[09:47] <adeuring> stub: ok, I'll see what we can remove or if we can make the function at lkeast simpler
[09:47] <stub> adeuring: I don't think any tests beyond the text search ones test the weird cases, and feel free to rewrite that horrible ftq() function entirely. Nobody should ever let me write parsers because I don't know what the hell I'm doing.
[09:47] <adeuring> stub: ;)
[09:48] <stub> adeuring: I do recommend reading the text search docs in the PG manual if you haven't already - if nothing else, it will get you familiar with the language and what problems you should be considering
[09:48] <adeuring> stub: yeah, I'm already looking into the docs
[09:55] <ivory> frankban: could you please look at this mp: https://code.launchpad.net/~ivo-kracht/launchpad/bug-353097/+merge/110018
[09:55] <frankban> sure ivory
[10:09] <jml> so a private team can't be a product owner?
[10:18] <jml> so, I was thinking about Launchpad's microservice idea last night
[10:18] <jml> and thinking about splitting out codehosting
[10:18] <jml> and then I thought that you'd probably want to split out the xml-rpc service that codehosting talks to
[10:19] <jml> but then I thought, LP used to have a separate xml-rpc service that codehosting talked to, and we rolled it into the appserver
[10:19] <jml> What has changed between then and now such that splitting it out again is a good idea? (Is it a good idea?)
[10:21] <jml> If a private team can't be a product owner, then I guess that means that private teams cannot have commercial subscriptions
[10:21] <czajkowski> jml: you did a lot of thinking last night :)
[10:22] <wgrant> jml: Private teams can be project owners.
[10:22] <wgrant> jml: I'm not sure if it's meant to be allowed yet, but we intend to allow it in future, and there is at least one case on production already that I know about.
[10:24] <jml> wgrant: http://paste.ubuntu.com/1038782/ says otherwise.
[10:25] <wgrant> jml: Yeah, as I thought, it's not currently allowed. But https://launchpad.net/convoy is the production example I was thinking of.
[10:26] <jml> wgrant: ok, thanks
[10:26] <jml> we're in testfix mode now. I'm guessing it's due to the failure on the db_lp slave.
[10:26] <wgrant> It was more than likely spurious, can you retry?
[10:27] <wgrant> If you're there.
[10:27] <jml> I am. Just did.
[10:27] <wgrant> Thanks.
[10:29]  * jml wonders how long it takes for pqm to switch out of testfix
[10:30] <lifeless> jml: splitting out the bzr codehosting stuff doesn't imply splitting out the xmlrpc service
[10:30] <jml> lifeless: I know that.
[10:30] <lifeless> jml: the xmlrpc service talks to the LP db, it needs to stay unsplit, most vigorously.
[10:30] <lifeless> 22:18 < jml> and then I thought that you'd probably want to split out the xml-rpc service that codehosting talks to
[10:31] <lifeless> jml: ^ what did you mean by that then ?
[10:31] <jml> lifeless: I meant "want" rather than "need"
[10:31] <lifeless> jml: so I'm asserting that want is wrong.
[10:31] <jml> lifeless: so what's the principle, that only the appserver should talk directly to the db?
[10:31] <lifeless> yes.
[10:31] <lifeless> thats declared in the SOA docs FWIW.
[10:32] <lifeless> most of our scripts should be moved out of the core tree into API clients, for instance.
[10:32] <lifeless> the buildmaster likewise.
[10:32] <jml> lifeless: where abouts?
[10:32] <lifeless> one or more anciliary projects
[10:33] <jml> lifeless: yeah, the buildmaster is the other one I think about from time to time
[10:33] <lifeless> validated test doubles to preserve the contracts they need and let them be tested robustly.
[10:33] <jml> lifeless: it's fruit is higher up the tree
[10:33] <jml> lifeless: I mean, whereabouts is the "only appserver should talk to the DB" written? I don't recall it and a quick grep doesn't find it.
[10:34] <jml> s/it's/its/
[10:36] <lifeless> its not a rule-rule yet, because it would create massive instantaneous debt, but its a meme I keep harping on. The closest actual rule-thing for it is...
[10:38] <lifeless> https://dev.launchpad.net/ArchitectureGuide/ServicesAnalysis#Contracts_and_protocols
[10:38] <jml> lifeless: I guess I'm mostly interested in why it's a desirable thing.
[10:39] <lifeless> which has 'Access to a particular form of persistence (e.g. the librarians files-on-disk, or a particular postgresql schema) requires being in the same source tree as the definition of that persistence mechanism.'
[10:39] <lifeless> jml: managing complexity
[10:39] <jml> "Access to a particular form of persistence (e.g. the librarians files-on-disk, or a particular postgresql schema) requires being in the same source tree as the definition of that persistence mechanism."
[10:40] <lifeless> jml: two different servers means either db model code running in two different (perhaps wildly so) contexts, or just redundancy in layout
[10:40] <jml> lifeless: that makes sense, thanks.
[10:42] <lifeless> jml: anytime, I'm sure I put that in there somewhere
[10:43] <wgrant> However, most of codehosting's model probably doesn't belong in the main LP DB.
[10:43] <wgrant> :)
[10:44] <lifeless> wgrant: lp:~wgrant/launchpad/dspc-trgm-indices into lp:launchpad
[10:44] <lifeless> sholdn't thast be db-devel ?
[10:44] <wgrant> lifeless: Should be doable hot.
[10:44] <lifeless> absolutely, but,..
[10:45] <wgrant> Hot patches go to devel.
[10:45] <lifeless> unless jml butchered it, no they don't.
[10:45] <wgrant> We've done it this way since last year...
[10:45] <wgrant> Why wouldn't they?
[10:45] <wgrant> Hot index patches have always been applied live and landed on devel.
[10:45] <lifeless> nearly 11pm, not the time for me to be thinking about this.
[10:46] <lifeless> worth checking the history on https://dev.launchpad.net/PolicyAndProcess/DatabaseSchemaChangesProcess and seeing if a 'cleanup' actually made it incorrect.
[10:46] <wgrant> I haven't read that page this year :)
[10:46] <wgrant> So a recent cleanup certainly hasn't changed my view of it.
[10:47] <wgrant> Anyway, landing live-applied DB patches on db-devel provides no benefit and lots of confusion, so we shouldn't do it.
[10:47] <wgrant> But tomorrow :)
[10:47] <lifeless> wgrant: qa might be part of it, I'll have to page it in. Tomorrow
[10:48] <lifeless> also, you edited it in may, fibber ;)
[10:48]  * lifeless goes to sleep
[10:48] <wgrant> I didn't read it.
[10:48] <wgrant> I knew exactly the part that needed fixing :)
[10:49] <jml> lifeless: I'm pretty sure I didn't touch hot vs cold patches.
[10:49] <jml> g'night.
[10:51] <wgrant> cjwatson: Your column rename is done.
[10:51] <wgrant> cjwatson: You can remove the compat code.
[10:51] <wgrant> jml: Yours should happen on Friday.
[10:52] <jml> wgrant: hurrah.
[10:54] <jml> I'm keen to mark the LP side of our LP integration work as done.
[10:55] <stub> wgrant: We already have a GIN index on distributionsourcepackagecache(fti)
[10:55]  * stub checks if his branch landed
[10:55] <wgrant> stub: Oh right, just not in devel yet.
[10:55] <wgrant> It's in db-devel
[10:55] <wgrant> Next up
[10:55]  * wgrant removes that one.
[10:56] <ivory> frankban, rvba: thanks for the reviews
[10:56] <rvba> You're welcome ivory.
[10:56] <frankban> ivory: welcome
[11:09] <cjwatson> wgrant: Great, thanks.
[12:09] <cjwatson> I could use reviews of https://code.launchpad.net/~cjwatson/launchpad/pocket-permissions/+merge/110037 and https://code.launchpad.net/~cjwatson/launchpad/packageset-score-rename-finish/+merge/110046
[12:58] <cjwatson> gmb: I tried your suggestion in https://code.launchpad.net/~cjwatson/launchpad/export-change-override/+merge/109549 (http://paste.ubuntu.com/1038961/), but two problems: firstly, the title= override doesn't seem to take so the title is wrong in apidoc (it says "The priority being published into", which is less helpful); secondly, tests fail with http://paste.ubuntu.com/1038963/ suggesting that the magic translation ...
[12:58] <cjwatson> ... doesn't actually happen.
[12:59] <cjwatson> gmb: Do you know what I might be doing wrong?
[14:04] <deryck> adeuring, https://plus.google.com/hangouts/_/5aac2d43bc403742ae3a25334fb32476561cab82?authuser=0&hl=en
[15:18] <jamestunnicliffe> Hi, anyone got any idea why the expander icons have vanished from https://launchpad.net/~linaro-infrastructure/+upcomingwork ? The work with a recently merged (an hour ago) local instance.
[15:22] <jml> jamestunnicliffe: I think there might be a  known issue with sprites & chrome
[15:22] <jml> jamestunnicliffe: but I'm not 100% sure, and I don't have a bug number.
[15:24] <jamestunnicliffe> jml: Thanks. Firefox does show the sprites.
[15:24] <rick_h> looking, I wasn't aware we had any sprite issues.
[15:24] <sinzui> jamestunnicliffe, I think wallyworld has a fix for that. This affects webkit browsers.
[15:24] <rick_h> ah, it's the empty content
[15:25] <rick_h> if I put any content in there I get the sprite
[15:26] <sinzui> rick_h, it is more subtle than that. There is a leading space *before* the anchor. New webkit can show empty content, but space normalisation and stripping interfere
[15:26] <sinzui> rick_h, I still believe empty anchors are invalid though
[15:26] <rick_h> sinzui: yea, I'm pretty sure they are as well.
[15:27] <rick_h> wheee, the browser dance here's your chance...browser dance...do the browser dance... :)
[15:28] <sinzui> webkit wins one technical merit. gecko wins because it does what you expects
[15:32] <sinzui> jamestunnicliffe, report the missing expanders as a new bug and add the regression tag. wallyworld's fix does not fix the missing expanders
[15:33] <jamestunnicliffe> sinzui: Will do. Thanks for looking into it.
[15:45] <sinzui> deryck, abentley, mrevell, flacoste: I have written all that I recall proprietary projects need to do with bug linking. I think we can find the essential use cases from this http://blog.launchpad.net/general/bug-linking-part-2
[15:45] <mrevell> Thanks sinzui
[15:45] <abentley> sinzui: thanks.
[15:46] <czajkowski> sinzui: just posting it t places now
[15:46] <czajkowski> thanks
[15:46] <flacoste> adeuring: congratulate ivorykr8 for his first landing!
[15:47] <sinzui> oh, did he use my suggested text?
[15:47] <adeuring> flacoste: thanks, but congrats shoukd go to ivory
[15:47] <flacoste> ah, i wasn't sure if he renamed himself
[15:48] <flacoste> ivory: congrats on your first landing! should be out to qastaging pretty soon
[15:48] <czajkowski> ivory: well done
[15:49] <sinzui> it only took me 18 months to write that sentence
[15:51] <deryck> sinzui, thanks for writing that up.
[16:39] <czajkowski> jamestunnicliffe: have you seen  https://bugs.launchpad.net/launchpad/+bug/1004416   wondering how similar it is to the one you just reported.
[16:39] <_mup_> Bug #1004416: Work Items not allowing users to edit them properly <work-item-tracker> <Launchpad itself:Triaged by linaro-infrastructure> < https://launchpad.net/bugs/1004416 >
[16:50] <sinzui> czajkowski, I think they are the same issue
[16:51] <czajkowski> sinzui: I thought so too but wanted to check as I've tried to recreate the blueprint one but not seeing the issue, but I know others are having issues with them
[17:53] <timrc> Hi, my understanding is that subscribing an individual to a Private PPA via the Manage Access view gives them "read" access to the PPA.  Someone just reported that they attempted to do this for an individual, but they were unable to access +packages? How would I go about giving an individual read-only access to the PPA in terms of installing packages and accessing the UI?
[18:31] <lifeless> sinzui: bug 1012787 - what mails are going to the team membership ? {I'm wondering if its unneeded complexity and that the actual problem is unnecessary notification emails/implicit subscriptions}
[18:31] <_mup_> Bug #1012787: cannot team restrict emails to go to the team admin <email> <linaro> <teams> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1012787 >
[18:38] <sinzui> lifeless, joey can provide example of emails that he does not want members to get
[19:01] <joey> aloha
[19:01] <lifeless> aloha
[19:01] <lifeless> so, what are the symptoms you're seeing ?
[19:02] <joey> I'll email you, lifeless, and sinzui,  a typical example
[19:05] <sinzui> thank you
[19:06] <joey> ok it's on it's way to your @c.c ids
[19:16] <joey> sinzui: lifeless - btw there's one more thing
[19:17] <joey> sinzui: lifeless - when IS makes a change to the teams for example, I get a raft of "Security exposure! This guy isn't part of Linaro. He's touching our stuff!" emails
[19:17] <joey> sinzui: lifeless - It's a headache since it happens a lot
[19:17] <joey> sinzui: lifeless - that's part of the reason I went to ~linaro-sysadmins so they see my name on it and mostly they ignore it
[19:17] <sinzui> joey. That last part is very interesting
[19:18] <joey> sinzui: yeah I have to imagine other projects may get that from time to time
[19:18] <joey> sinzui: especially when they touch private teams
[19:19] <joey> czajkowski: ^^
[19:28] <lifeless> joey: that refers to mail from linaro folk that don't recognise e.g. stephanie miller ?
[19:28] <joey> lifeless: correct
[19:29] <joey> lifeless: they rightfully query me which is good but you see the overall issue
[19:30] <joey> I guess to some extend Linaro might be a special case but if was with, say, Mozilla, and someone did that  they didn't know they would probably have a similar reaction
[19:39] <czajkowski> sinzui: in all the disclosure work you're doing, is there anything being done to tell people the bug they are trying to view is a private bug so they understand when they cant find it ?
[19:41] <sinzui> czajkowski, We are still debating this. private things are officially 404 and we do not talk about privacy
[19:41] <czajkowski> well it would cut down on questions we get a lot of https://answers.launchpad.net/launchpad/+question/200348
[19:41] <sinzui> czajkowski, the underlying problem is the people (and bots) are inconsiderate of others when marking bugs duplicates
[19:42] <czajkowski> it's not clear to users why they cant see it but it's being referenced so it's confusing
[19:42] <sinzui> I hope that Lp will force users to be considerate when the Orange Mafia work on bug linkings
[19:43] <czajkowski> if there is no bug open on this will create one as I think it'd be good to address
[19:43] <sinzui> czajkowski, private bugs in non-commercial projects should never be the master of a duplicate. People and bots are being complete and utter bastards to other users
[19:43] <czajkowski> the current error or lack of information is not ideal.
[19:43] <czajkowski> sinzui: no arguements from me there :)
[19:43] <sinzui> We have several open bugs
[19:44] <czajkowski> sinzui: I only understand this now from working on LP, before I used to find it rude and annoying, now I just find it annoying
[19:44] <sinzui> bug 434733 I cited in my blog bost today is the one users most care about
[19:44] <_mup_> Bug #434733: marking public bug as duplicate of private bug leads to confusing UI <chr> <confusing-ui> <lp-bugs> <privacy> <qa-untestable> <ui> <Launchpad itself:In Progress by stevenk> < https://launchpad.net/bugs/434733 >
[20:02] <joey> sinzui: the way I've begun to look at things now is with a UX hat on.  It's not sufficient to say "my service isn't responsible".  If the service is able to help mitigate a social problem, oftentimes it's worth the time and effort (assuming it's done correctly)
[20:02] <joey> sinzui: and it helps to clear up ill perceptions
[20:12] <lifeless> czajkowski: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/764414
[20:12] <_mup_> Bug #764414: private master bugs are confusing and lead to more duplicate filings <pet-bug> <apport (Ubuntu):Triaged by pitti> < https://launchpad.net/bugs/764414 >
[20:12] <lifeless> joey: ^
[20:12] <lifeless> thats the root cause; its what causes the bad experience.
[20:12] <lifeless> We could fix it in a heartbeat, by stopping apport doing it.
[20:13] <lifeless> But that would be a litle unreasonable to do unilaterally.
[20:14] <czajkowski> lifeless: thanks.
[20:14] <czajkowski> never seen a tag - pet-bug before
[20:17] <joey> yeah I remember that bug :-)
[20:17] <joey> caused me grief in OEM
[20:17] <czajkowski> joey: why ?
[20:17] <joey> in the OEM days public was public and private was NDA'd so you couldn't even acknowledge the two
[20:18] <joey> so you might have a public Ubuntu bug that was created and a dup of a private OEM bug, but you could do touch it
[20:18] <czajkowski> ah gotcha
[20:18] <joey> but anyway, there is usually a solution if you can think out of the box and, crucially, have some resource to work on it
[20:19] <joey> in the bug lifeless mentioned, you can't futz with apport because it'll break things
[20:19] <joey> but you could have a background service process that interrogates bugs and does bug matching...but that is very expensive
[20:20] <joey> and I fear the algorithm would be more prone to failure than success
[20:20] <lifeless> joey: we can change apport, pitti in principle agreed to what I suggested.
[20:20] <lifeless> joey: the problem is resources.
[20:21] <joey> lifeless: Good to know. I guess you solved it somehow other than making apport aware of private bugs?
[20:21] <joey> apport on the client machine that is
[20:21] <lifeless> joey: huh? this isn't client side.
[20:21] <lifeless> joey: its all server side + how devs do their bug management.
[20:21] <joey> lifeless: ok you just confirmed my suspicion
[20:22] <lifeless> joey: the apport retracer is the thing that makes bug A a dupe of bug Master.
[20:22] <lifeless> And bug Master is allowed to be private.
[20:22] <joey> ah right, that's where I was headed with the service process comment above...was just being a bit general
[20:22] <joey> still, you need dev time to make it happen
[20:23] <joey> anyway, dead horse :-)
[20:23] <lifeless> joey: *we* don't, Ubuntu do :)
[20:24] <lifeless> joey: this isn't something we can directly fix :(
[20:24] <joey> lol
[20:24] <lifeless> Even supplying a patch isn't enough, the stuff that needs finesse and time is social.
[20:39] <lifeless> sinzui: so joeys mail; the point solution there is perhaps 'only tell admins about team join events', that is there is no action for members to take.
[20:39] <lifeless> or maybe even only owners.
[20:39] <sinzui> lifeless, admins I think. the owner can be an admin if he chooses
[20:39] <lifeless> members are not expected to do anything as a result of a team join (ignoring mailing lists for a second)
[20:40] <sinzui> lifeless, and if this is the case, I suspect we can duplicate this bug
[20:40] <lifeless> sinzui: for mailing lists, they still don't need to do anything, unless their list preference is 'ask me about subscribing when I join a list team'
[20:40] <lifeless> joey: are there other sorts of mails than that one that you sent us ?
[20:41] <sinzui> lifeless, agreed
[20:41] <joey> lifeless: that's the standard mail I receive along with the "who's Stephanie Miller and why is she touching our Linaro stuff?" emails.
[20:42] <joey> sinzui: lifeless - I'm ok with admins vs owners.
[20:42] <joey> sinzui: lifeless - just anything other than rank and file members
[20:42] <joey> If I think about it, admin is the probably the correct decision
[20:42] <sinzui> joey owners can leave the team, they have delegate the running of it to the admins.
[20:43] <sinzui> owner can take back control if they want
[20:43] <joey> sinzui: well in my case, ~linaro-sysadmins are not members, only owners
[20:43] <joey> sinzui: so I guess I'd need both owner and admin
[20:43] <sinzui> ah, so they should not ever get notifications.
[20:43] <joey> I'm sure if you do it one way someone will complain that they want it the other
[20:44] <joey> sinzui: in my case, having ~linaro-sysadmins as part of the team screws up the milestone view in LP so we have to remove them for metrics and such
[20:44] <sinzui> joey, can I see en example of a team that ~linaro-sysadmin owns
[20:44] <joey> sinzui: think  status.linaro.org
[20:44] <joey> sinzui: ~linaro
[20:44] <joey> sinzui: actually, anything ~linaro and ~linaro-*
[20:45] <joey> sinzui: also we have some private or access restricted teams and we don't want members/partners/etc looking at the team list and wondering who the sysadmins are
[20:45] <joey> just prevents questions
[20:45] <joey> is that a firm requirement? no
[20:45] <sinzui> joey, https://launchpad.net/~linaro/+members says ~linaro-sysadmin are the only admins
[20:45] <joey> sinzui: yeah that's the one case :-)
[20:46] <joey> sinzui: look at any of the sub-teams
[20:52] <joey> sinzui: I suppose the safer approach is admins & owners but the more expensive approach is a tick box for each.  Just me thinking out loud. You're the right brain to noodle on it.
[20:52] <sinzui> joey, we really make a point of not contact owners that are not admins
[20:53] <joey> sinzui: I think I can live that
[20:53] <joey> sinzui: I miss the change notifications but frankly, if something is not working, someone is going to me
[20:53] <joey> sinzui: and eventually ping the linaro sysadmins
[20:53] <joey> sinzui: and I do want the team admins to be fully engaged in their teams
[20:54] <joey> sinzui: so I can deal with admin only
[20:54] <joey> sinzui: I've often wanted a "reason box" when adding people just like deleting them but that's another story for another day :-)
[20:56] <sinzui> joey. I too see a cluster of issues here that would be nice to fix in a single branch. Limit who gets the email, fix the headers and rationale, state in the UI who gets the emails
[22:11] <sinzui> jcsackett, mumble?
[22:36] <wgrant> benji: Is your removal of logs/ just a day after its creation deliberate?
[22:54] <cjwatson> Hm, OCR not on channel
[22:54] <cjwatson> I'd like to get https://code.launchpad.net/~cjwatson/launchpad/pocket-permissions/+merge/110037 landed in the not too distant future, since the code on prod is broken (not a regression, but still).  Anyone up for a review of some URL traversal code?
[22:55] <wgrant> cjwatson: Looking.
[22:57] <wgrant> 37	item = ("type=packageset&item=%s&series=%s" %
[22:57] <wgrant> 38	(self.context.package_set_name,
[22:57] <wgrant> 39	self.context.distro_series_name))
[22:57] <wgrant> Ew
[22:58] <StevenK> wgrant: If you make some broad statement about that line wrapping being as bad as mine, I might have to get offended. :-P
[22:58] <wgrant> Not line-wrapping.
[22:58] <wgrant> That code is just wrong :)
[22:58] <cjwatson> wgrant: That's the pre-existing bit isn't it?
[22:58] <wgrant> It is, yes.
[22:58] <wgrant> It's also horrible.
[22:58] <wgrant> But not your fault.
[22:58] <cjwatson> (For my edification, what's horrible?)
[22:59] <wgrant> You can't just stuff arbitrary strings into application/x-www-form-encoded and hope it works.
[22:59] <wgrant> eg. if a name contains + that will break.
[22:59] <cjwatson> Entertaining
[22:59] <wgrant> application/x-www-form-urlencoded, that is
[23:00] <cjwatson> Should it be escaped or totally rearranged? :-)
[23:00] <cjwatson> (Academic since I hope not to have to touch that again.)
[23:02] <wgrant> "escaped" is the wrong way to think about it. The query string should be formed using urllib.urlencode({'type': 'packageset', 'item': self.context.package_set_name, 'series': self.context.distro_series_name}) or so.
[23:03] <wgrant> cjwatson: r=me
[23:03] <wgrant> Feel free to rewrite that doctest to be unit tests that are about 90% smaller, but I doubt I can convince you to do that...
[23:04] <cjwatson> Well, I've done it for a bunch of my other branches recently
[23:05] <cjwatson> In this case I sort of want to get the fix in quickly rather than spending another half a day rewriting doctests, though
[23:05] <wgrant> Exactly :)
[23:05] <cjwatson> How about I queue it up as first against the wall for the next time I want LoC?
[23:05] <wgrant> It's fine as it is.
[23:05] <wgrant> But yes, that would indeed be a good idea.
[23:05] <cjwatson> "fine" in the limited sense that any doctest can be fine.
[23:05] <wgrant> doctest-slaying is a pretty good way to get LoC
[23:06] <cjwatson> Most of the time, yeah.
[23:06] <cjwatson> I'm not convinced my xx-*-package-publishing.txt rewrite is going to be much of a wine
[23:06] <cjwatson> *win
[23:08] <cjwatson> wgrant: Thanks, sending to EC2.  I hope it sticks this time.
[23:08] <wgrant> cjwatson: Seems like it should. Thanks for fixing that.
[23:13] <lifeless> hmm, js.js for foreign sourced scripts
[23:14] <cjwatson> wgrant: I'd still like to get the queue-api review finished, but that might be a bit much for first thing in the morning. :-)
[23:15] <wgrant> lifeless: Along with its nodejs integration, js.js.js?
[23:17] <wgrant> cjwatson: Looking at your others new.
[23:17] <wgrant> queue-api will be done gradually over the day, I suspect :)
[23:17] <wgrant> packageset-score-rename-finish approved
[23:17] <cjwatson> Heh, yeah
[23:18] <wgrant> What's export-change-override up to?
[23:18] <cjwatson> I queried gmb about his comment earlier today, but haven't heard back.
[23:18] <cjwatson> 13:58 <cjwatson> gmb: I tried your suggestion in https://code.launchpad.net/~cjwatson/launchpad/export-change-override/+merge/109549 (http://paste.ubuntu.com/1038961/), but two problems: firstly, the title=
[23:18] <cjwatson>                  override doesn't seem to take so the title is wrong in apidoc (it says "The priority being published into", which is less helpful); secondly, tests fail with http://paste.ubuntu.com/1038963/
[23:18] <cjwatson>                  suggesting that the magic translation ...
[23:18] <wgrant> Ah
[23:18] <cjwatson> 13:58 <cjwatson> ... doesn't actually happen.
[23:18] <cjwatson> 13:59 <cjwatson> gmb: Do you know what I might be doing wrong?
[23:18] <wgrant> Saw that but forgot about it, indeed.
[23:19] <wgrant> cjwatson: If you're going to make it more widely available, you might consider fixing bug #530020 while you're there
[23:19] <_mup_> Bug #530020: change-override.py should forbid modifications of the RELEASE pocket of non-development series <lp-soyuz> <soyuz-ftpmaster-tools> <soyuz-publish> <Launchpad itself:Triaged> < https://launchpad.net/bugs/530020 >
[23:19] <cjwatson> p-s-r-f: thanks, can I have Status: Approved and I'll land it?
[23:19] <cjwatson> Oh, interesting
[23:19] <wgrant> Hm, I did.
[23:19] <wgrant> Maybe I have too many MPs open so longpoll is killing the world.
[23:19] <wgrant> Indeed.
[23:19]  * StevenK stabs longpoll
[23:19] <wgrant> Fixed.
[23:21] <lifeless> wgrant: js.js.js would be most fun
[23:21] <cjwatson> Happy to stall export-change-override on 530020, though probably not tonight.
[23:22] <wgrant> cjwatson: Should be a ~2-line fix + tests, and it seems like a good idea to do it before exposing it, so that'd be nice, thanks.
[23:23] <cjwatson> Well, ~4 'cos there are two changeOverride methods to consider, but yes :-)
[23:23] <wgrant> True.
[23:26] <StevenK> wgrant: Oh, HAH.
[23:26] <StevenK> wgrant: IBranchNamespace.createBranch() still had explicitly_private in it.
[23:26] <wgrant> That would do it.
[23:30] <StevenK> I'm using test_branchmergeproposal as my canary, and I've dropped from 305 failures to 24. Something else is touching transitively_private inappropiately.
[23:39] <StevenK> Right, 1 failure, and that's 2.7
[23:39] <StevenK> wgrant: So I want to stop setting them too?
[23:40] <wgrant> The DB columns still need to be set in the first branch.
[23:40] <wgrant> But they must not be read.
[23:45] <wgrant> wallyworld: Bug #1012912 might be of interest. Found it during QA of your changes from yesterday, but it's not a regression in them.
[23:45] <_mup_> Bug #1012912: +filebug choice popups break when the user is unprivileged <disclosure> <javascript> <trivial> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1012912 >
[23:46] <wallyworld> ok, will fix thanks
[23:54] <StevenK> wgrant: http://pastebin.ubuntu.com/1039933/
[23:56] <wgrant> StevenK: If that fixes it.
[23:56] <StevenK> wgrant: Drops the failures from 305 to 1, and that one is a 2.7 thing.
[23:58] <wgrant> Sounds good.
[23:58]  * StevenK re-tosses at ec2