[00:02] <wgrant> StevenK: It depends how you use setUpFields() to fiddle with the schema.
[00:29] <StevenK> wgrant: http://pastebin.ubuntu.com/1013974/
[00:30] <wgrant> StevenK: Myes?
[00:38] <StevenK> wgrant: I was having breakfast -- that diff is in relation to the question I asked you earlier.
[00:40] <wgrant> StevenK: If it works, great. If it doesn't work, that doesn't tell me why it doesn't work :)
[00:42] <lifeless> cjwatson: have you not been exposed to my 'imperative bug reports considered harmful' meme ?
[00:43] <cjwatson> I don't think I used imperative "should" anywhere in that
[00:43] <cjwatson> Oh, the title.  Whatever.  Rephrase as you see fit; I must say I entirely fail to see the point in that meme.
[00:43] <lifeless> cjwatson: the title is imperative;) - its an imperative I agree with :)
[00:43] <cjwatson> And I generally have trouble figuring out what you think I'm supposed to write instad.
[00:43] <cjwatson> *instead
[00:45] <lifeless> in this case, I'd have said something like 'queue tool requires direct DB access'
[00:45] <cjwatson> OK.  I don't really see the benefit in spending time on consolidating the grammatical voice of bug titles, though; it seems like a very minor point at best.
[00:47] <cjwatson> Perhaps this is the natural result of developers needing to file bugs for work they already have in progress in order to provide a place for QA tags to go.
[00:47] <StevenK> wgrant: http://pastebin.ubuntu.com/1013992/
[00:48] <cjwatson> That'll tend to result in people describing what they're doing rather than describing the original problem.
[00:48] <cjwatson> Anyway, rephrased the title, but I can't promise to remember in future.
[00:49] <lifeless> cjwatson: I think the QA story is indeed part of the situation
[00:50] <lifeless> cjwatson: I find imperative bugs from devs or non-devs are equally likely to age terribly; yours wouldn't because the description is comprehensive
[00:50] <wgrant> StevenK: Sounds like you have information_type in field_names.
[00:51] <lifeless> cjwatson: also you're about to land a change, which makes the aging aspect less of a concern
[00:51] <StevenK> wgrant: I'm supposed to?
[00:52] <wgrant> StevenK: The default LaunchpadForm.setUpFields sets up fields that you specify.
[00:53] <cjwatson> lifeless: Well, hoping that I actually get all the way through the several incremental changes in this series ;-)
[00:53] <wgrant> StevenK: Unless information_type is in the schema that setUpFields is using, putting it in field_names isn't a very good idea.
[00:53] <wgrant> StevenK: The fact that you override setUpFields to add in information_type manually suggests that it doesn't belong in field_names.
[00:56] <StevenK> wgrant: If I drop it from field_names then it doesn't show up at all
[00:58] <wgrant> StevenK: Ah, perhaps the default form template uses field_names to determine the order.
[00:58] <wgrant> StevenK: Why did you move information_type_field into setUpFields anyway?
[00:58] <wgrant> It doesn't depend on anything there,
[00:59] <wgrant> StevenK: Normally you'd tweak field_names at some point, not just overriding the schema field because you can.
[00:59] <StevenK> wgrant: I need to override the schema field for the vocab
[00:59] <wgrant> Also, super()
[01:00] <wgrant> This isn't Python 2.1.
[01:02] <StevenK> Same error with super()
[01:02] <wgrant> super() is unrelated here, it's just that your code was looking like it belonged in 2002.
[01:04] <wgrant> StevenK: Grep for form_fields.omit
[01:04] <wgrant> To see the usual pattern.
[01:05] <StevenK> wgrant: I can put it in BranchEditSchema, but the vocab doesn't respect the flags
[01:06] <wgrant> StevenK: If you really can't put it in the schema, you'll probably have to use the super/omit/+= approach.
[01:07] <StevenK> wgrant: Right, so it stays in field_names, but then I omit and re-add it
[01:07] <wgrant> StevenK: Except that this whole thing wants to be feature-flagged.
[01:08] <wgrant> Observe BugSecrecyEditView
[01:19] <cjwatson> lifeless: I don't mean to be awkward, by the way.  Just found it hard to see the importance of it.  If you think it makes a measurable difference to how useful bugs are a while after they've been filed, fair enough.
[01:20] <lifeless> cjwatson: The prototypical poor bug looks like this
[01:20] <lifeless> "Do X"
[01:20] <lifeless> "Something detailed about the change"
[01:21] <lifeless> usually, when I ask the filer 6 months or a year later, they have no detailed recollection for what prompted them to file the bug
[01:21] <lifeless> that is, the symptoms are long forgotten
[01:21] <cjwatson> Yeah, I can see that being troublesome
[01:22] <lifeless> so my actual thing is that we should always record the symptoms
[01:22] <lifeless> and that as a mind-hack, avoiding imperatives seems to encourage capturing the symptoms vs the fix
[01:22] <cjwatson> Ah, see, I would have found "record the symptoms" a much clearer way to put it than "no imperatives".
[01:22] <cjwatson> Your mind-hack bounced off me :)
[01:23] <lifeless> indeed
[01:24] <lifeless> the other, *much weaker* aspect is that in bug listings, having symptoms visible helps figure out if you're looking at the right bug
[01:24] <cjwatson> (Because, I think, "no imperatives" reminded me too much of pseudogrammatical nonsense like "passive voice is naughty".)
[01:24] <lifeless> I say weaker because you can click through and if the description is maintained or just good, its only time
[01:24] <lifeless> cjwatson: yes, martin pool also fell down that path
[01:25] <lifeless> I need to evolve how I present this, I think.
[01:25] <mwhudson> hello, i'm michael i work for a software company called 'pedantical'
[01:25] <lifeless> MPT has filed dozens, if not hundreds of these poor bugs btw
[01:25] <lifeless> with pages of exposition
[01:25] <lifeless> but missing the actual symptoms.
[01:25] <lifeless> He changed some years in and started recording symptoms too
[01:26] <lifeless> its quite dramatic when you scan through a couple K bugs, what patterns the brain finds :)
[01:26] <StevenK> wgrant: Right, so I was attempting to do the same, but there's an adapter in BranchEditView
[01:26] <wgrant> StevenK: An adapter?
[01:27] <StevenK>     def adapters(self):
[01:27] <StevenK>         """See `LaunchpadFormView`"""
[01:27] <StevenK>         return {BranchEditSchema: self.context}
[01:27] <StevenK> With a @property
[01:28] <wgrant> StevenK: Um
[01:28] <wgrant> StevenK: BranchEditView already has a tonne of logic for this sort of thing.
[01:28] <wgrant> Sometimes showing the private field, sometimes not
[01:28] <wgrant> Using custom widgets
[01:28] <wgrant> in setUpFields.
[01:28] <StevenK> wgrant: Yes, have you seen my diff?
[01:29] <wgrant> StevenK: Yes, and it doesn't make much sense.
[01:29] <wgrant> Because it's defining a setUpFields when there already is one.
[01:29] <wgrant> Unless you're defining it on a superclass -- hard to tell from that diff.
[01:30] <StevenK> wgrant: Sorry, I meant the total diff. http://pastebin.ubuntu.com/1014035/
[01:30] <wgrant> Ah, BranchEditFormView
[01:30] <StevenK> Yes.
[01:30]  * StevenK stabs it
[01:30] <wgrant> StevenK: Line 258
[01:31] <StevenK> Ah, so the setupFields in BranchEditFormView will never get called
[01:31] <wgrant> Correct.
[01:31] <wgrant> THis is why we shouldn't write code like it's 2002.
[01:32] <wgrant> Because it's not 2002.
[01:32] <StevenK> wgrant: But the adapter I pasted above is why I can't do what BugEditSecrecyView does
[01:32] <wgrant> In fact, maybe I should grep for anything calling a method on a CamelCase identifier and kill it :)
[01:34] <wgrant> StevenK: Why can't you put it in BranchEditSchema? Does the vocab evaluate the flag at instantiation time?
[01:38] <StevenK> wgrant: It was there originally, but it looks like the flag doesn't take effect
[01:39] <wgrant> I'd perhaps work out why it's not taking effect.
[01:42] <StevenK> wgrant: The class is at the top level, and the vocab has a () at the end so it happens at file read time?
[01:43] <wgrant> StevenK: If you instantiate it there, it will be insantiated there, indeed.
[01:43] <StevenK> wgrant: So I was trying to work around that like BugEditSecrecyView but that adapters thing uses the schema
[01:44] <wgrant> StevenK: Are you sure you can't override it?
[01:45] <wgrant> I mean, you may be able to do the usual thing in setUpFields.
[01:45] <wgrant> Or define the interface in a method somewhere.
[01:45] <wgrant> Or not instantiate the vocab at that point (I'm not sure if you have to)
[01:45] <wgrant> Or not use adapters.
[01:45] <wgrant> etc
[01:45] <wgrant> one of those ways will work
[01:46] <StevenK> wgrant: Why is the adapter even there?
[01:47] <wgrant> StevenK: Probably to adapt the data into the form required by the interface.
[01:47] <wgrant> Now
[01:47] <wgrant> I'm not sure it's entirely useful here, given that the adapter does nothing.
[01:48] <StevenK> It gives a fail to adapt if I remove it
[01:50] <wgrant> Well, yes, clearly removing the adapter is going to not work very well.
[01:51] <StevenK> wgrant: But you said it does nothing! :-)
[01:51] <wgrant> The adapter internally does nothing.
[01:51] <wgrant> Its presence does something, but it's probably not useful.
[01:51] <wgrant> That doesn't mean you can just delete its definition without consequence.
[01:51] <StevenK> If I change it from using BranchEditSchema to self.schema it also gives fail to adapt
[01:52] <wgrant> That's not really surprising, since self.schema is BranchEditSchema.
[01:52] <wgrant> So
[01:52] <wgrant> What I would try is the usual approach.
[01:52] <StevenK> But they should be equal :-(
[01:52] <wgrant> Define the class at view instantiation time.
[01:53] <wgrant> THey aren't just equal -- they are the same object.
[01:53] <wgrant> So changing from one to the other isn't going to change anything -- object identity holds between them.
[01:53] <StevenK> wgrant: I was doing that with def schema: class schema...
[01:53] <wgrant> StevenK: Right, that's probably the least invasive approach here.
[01:53] <wgrant> Try something that works.
[01:54] <wgrant> If it works, it's possibly a good idea.
[01:54] <wgrant> If it doesn't work, it's probably a good idea to try something else :)
[01:57] <StevenK> TypeError: ('Could not adapt', <Branch u'~person-name-100039/product-name-100042/branch-100046' (77)>, <InterfaceClass lp.code.browser.branch.BranchEditSchema>)
[01:58] <wgrant> StevenK: You're probably creating multiple instances of the class.
[01:58] <wgrant> Erm, wait, that's not a class defined inside the class
[01:58] <wgrant> You're still using the module-level one.
[01:59] <StevenK> wgrant: http://pastebin.ubuntu.com/1014057/
[02:00] <wgrant> StevenK: That has the obvious problem that the interface will be recreated each time self.schema is evaluated.
[02:01] <wgrant> Which is less than ideal, as the that means self.adapters will be returning a new interface each time, so it's entirely useless.
[02:01] <StevenK> I thought that was BugEditSecrecyView was doing?
[02:01] <wgrant> It's not adapting.
[02:02] <StevenK> Ah, true.
[02:02] <wgrant> It probably only evaluates self.schema once, and even if it does it multiple times it doesn't care about their identity.
[02:02] <wgrant> Just their content.
[02:02] <wgrant> Adaption cares about identity.
[02:03] <StevenK> :-(
[02:03] <lifeless> hmm
[02:03] <lifeless> anyhone happen to know, will the PPR consider e.g. memcache time as 'SQL' time ?
[02:03] <wgrant> lifeless: I believe so.
[02:03] <lifeless> wgrant: +login
[02:03] <wgrant> lifeless: AFAIK its logic predates non-SQL timedactions
[02:04] <lifeless> 1.4s 99th percentil, 0.2s 99th percentil of SQL
[02:04] <lifeless> so 1.2 seconds doing <what>
[02:04] <wgrant> Hm, maybe it's smarter than I thought
[02:04] <lifeless> We track at least one of our calls to SSO
[02:04] <lifeless> possibly the nested calls thing is it
[02:04] <lifeless> ah yes, that will be showing 0ms times
[02:04] <StevenK> Launchpad Production Errors
[02:05] <StevenK> OOPS Tools Production Errors
[02:05] <StevenK> Production Errors
[02:05] <StevenK> FAIL
[02:05] <wgrant>         sql_statements = da.get_request_statements()
[02:05] <wgrant>         sql_milliseconds = sum(
[02:05] <wgrant>             endtime - starttime
[02:05] <wgrant>                 for starttime, endtime, id, statement, tb in sql_statements)
[02:05] <lifeless> StevenK: if thats mail, great success
[02:05] <wgrant> lifeless: Oh, prod OOPSes are going to oops.c.c now?
[02:06] <lifeless> yes
[02:06] <lifeless> easing over
[02:06] <StevenK> lifeless: Oh, excellent. So now developers have to skip six useless mails a day rather than four
[02:06] <wgrant> :/
[02:06] <wgrant> Well
[02:06] <wgrant> More notably, it's now impossible to analyse OOPSes usefully.
[02:06] <lifeless> StevenK: we'll disable the other one shortly; then update the linkification logic
[02:06] <wgrant> We can't get the actual files or grep around to get trends etc.
[02:06] <lifeless> we haven't finish the setup
[02:07] <lifeless> its on a dedicated machine for scaling, and we should be able to get shell access
[02:07] <StevenK> So Oops gets a machine and LP Jenkins doesn't?
[02:12] <lifeless> I don't know where to even start
[02:14] <lifeless> bigjools: does maas use package django? just python-django ?
[02:15] <bigjools> lifeless: yeah pulls in the package
[02:34] <StevenK> wgrant: I wonder if I can have the schema out in the class and then override the field
[02:47] <wgrant> StevenK: Define it in the top level of the class body? That'll be a single interface for all instances of that class, so mutating it is not a good idea.
[03:07] <hbt272> hello
[03:08] <StevenK> wgrant: Mutating the field is a bad idea?
[03:08] <hbt272> anybody know vala langueges?
[03:08] <wgrant> StevenK: If the class is shared between all instances, yes.
[03:10] <StevenK> wgrant: It's used for BranchEditWhiteboardView BranchEditStatusView BranchEditView BranchReviewerEditView
[03:10] <StevenK> So it's probably safe to rip out and replace information_type in BranchEditView.setUpFields()
[03:11] <wgrant> StevenK: I mean the single interface class will be shared between BranchEditView etc. instances.
[03:11] <wgrant> So you'll be mutating semi-global state
[03:11] <wgrant> Just like if you had class Foo:
[03:11] <wgrant>    bar = []
[03:11] <wgrant> And started poking in bar, all instances would see it.
[03:12] <StevenK> wgrant: Right, I was going to leave information_type in BranchEditSchema withouth the vocab and then replace the field in BranchEditView.setUpFields()
[03:12] <wgrant> StevenK: But you can't modify BranchEditSchema if you do it like that.
[03:12] <lifeless> StevenK: wgrant: what are you guys cooking up?
[03:12] <wgrant> Well, you can, but it's evil and I'll reject it :)
[03:13] <StevenK> wgrant: I wasn't going to -- I was going to self.form_fields.omit() and so on
[03:13] <wgrant> StevenK: If you're going to do that, you needn't move BranchEditSchema at all.
[03:13] <wgrant> I thought you had a reason for not doing this.
[03:13] <wgrant> the adapter broke it or something.
[03:15] <StevenK> wgrant: Right, I have moved BranchEditSchema back
[03:16] <StevenK> TypeError: unsupported operand type(s) for +=: 'FormFields' and 'Choice'
[03:16] <StevenK> :-(
[03:17] <wgrant> += Fields(foo_field)
[03:19] <StevenK> from zope.formlib import form
[03:19] <StevenK> RARGH
[03:19] <StevenK> I hate that, and then form. is scattered all over the file
[03:20] <wgrant> Hope you never have to work on bzr :)
[03:20] <wgrant> They do it a bit.
[03:20] <wgrant> I'm not really a huge fan.
[03:20] <StevenK> I'm tempted to fix it in this file, but this branch is already 460 lines.
[03:21] <StevenK> % bzr grep 'from zope.formlib import form' | wc -l
[03:21] <StevenK> 28
[03:21] <StevenK> Maybe I will fix them
[03:21] <StevenK> (In a seperate branch)
[03:27] <wgrant> StevenK: It's a matter of opinion whether it's something that should be "fixed".
[03:28] <StevenK> wgrant: It annoys me... It may annoy me enough to bend the codebase to my will.
[03:30] <hbt272> how can to change gtk window background in vala langueges? Please help
[03:34] <StevenK> wgrant, wallyworld_: https://code.launchpad.net/~stevenk/launchpad/branch-information_type-ui/+merge/107909 would appreciate a review.
[03:34] <wallyworld_>  /me looks
[03:36] <wgrant> StevenK: Does that actually work?
[03:37] <wgrant> You aren't hiding explicitly_private when the flag is set.
[03:37] <lifeless> hbt272: this channel has nothing to do with gtk
[03:37] <lifeless> hbt272: I think you are not getting answers because people don't know. You would be better off asking in a desktop development channel.
[03:37] <wgrant> StevenK: Oh, you do that separately down the bottom. That's a bit odd. I'd just customise field_names based on the flag and have everything else depend on the contents of field_names.
[03:38] <hbt272> lifeless: thank you!
[03:39] <StevenK> wgrant: My reasoning behind that was two-fold: 1) The current rules look complex, and 2) We are going to revisit this anyway due to self-service, so thought it could stay put until then.
[03:40] <wgrant> StevenK: Does omit break if the field isn't there?
[03:43] <wgrant> StevenK: I'd replace the stuff in "if not show_private_field" with "self.form_fields = self.form_fields.omit('explicitly_private', 'information_type')"
[03:44] <wgrant> And the thing which replaces the field on line 257 of the diff with "if self.form_fields.get('information_type') is not None"
[03:45] <wgrant> That encapsulates the field selection logic in field_names.
[03:48] <wallyworld_> StevenK: sorry, got pinger by thumper, looks like wgrant is doing the review
[03:49] <wgrant> Yup
[04:04] <StevenK> wgrant: But information_type will always be not None?
[04:05] <wgrant> StevenK: Not if it's not there.
[04:06] <StevenK> wgrant: information_type is always in the schema
[04:08] <wgrant> StevenK: if 'information_type' in self.field_names, then.
[04:09] <StevenK> wgrant: Right, that sounds sensible
[04:11] <StevenK> wgrant: Are those your only two comments?
[04:12] <wgrant> StevenK: http://pastebin.ubuntu.com/1014176/
[04:12] <wgrant> Um, can revert the move of show_information_type_in_ui; that isn't necessary any more.
[04:13] <StevenK> Why moving the schema?
[04:13] <wgrant> So we don't have to override the field.
[04:13] <wgrant> We instead create the class when self.schema is evaluated.
[04:13] <wgrant> At which time the feature flag is already in place.
[04:14] <StevenK> But doesn't that end up with beng unable to adapt?
[04:14] <wgrant> Same thing as BugSecrecyEditView, except with @cachedproperty to preserve identity for adaption.
[04:14] <StevenK> *being
[04:14] <StevenK> Ah.
[04:22] <StevenK> wgrant: That looks excellent.
[04:30] <StevenK> wgrant: So you approve, or now I should get wallyworld_ to review it? :-)
[04:30] <wgrant> StevenK: Was waiting for the diff to update.
[04:30] <StevenK> It should be done
[04:30] <wgrant> Indeed.
[04:36]  * wallyworld_ laments that getPrecachedPersonsFromIDs doesn't seed the ValidPersonCache :-(
[04:36] <StevenK> wgrant: Did you see cjwatson's MP about CustomUpload?
[04:36] <wgrant> wallyworld_: ValidPersonCache is the most horrible thing in the world.
[04:36] <StevenK> ... aside from my indenting.
[04:37] <wgrant> wallyworld_: But there should be an option to getPrecachedPersonsFromIDs that cached it, I thought.
[04:37] <wgrant> StevenK: I veeeeery nearly said that.
[04:37] <StevenK> Hahahaha
[04:37] <wgrant> But decided it could be mean.
[04:37] <wallyworld_> wgrant: the api seems to indicate that but it doesn't work
[04:38] <wgrant> wallyworld_: How're you accessing it that it doesn't appear to be cached?
[04:38]  * StevenK wonders why LP pages are taking ~ 3 minutes to refresh
[04:38] <wgrant> StevenK: Because you have too many MPs open.
[04:39] <wallyworld_> wgrant: person.is_valid_person does a ValidPersonCahce query even after calling getUtility(IPersonSet).getPrecachedPersonsFromIDs(grantees, need_icon=True, need_validity=True)
[04:39] <StevenK> SIGH
[04:39] <StevenK> LONGPOLL!
[04:39] <wgrant> wallyworld_: Did you evaluate the resultset?
[04:39] <StevenK> wgrant: Can I have a +1 now?
[04:39] <wgrant> wallyworld_: getPrecachedPersonsFromIDs doesn't actually get precached persons from IDs.
[04:40] <wgrant> wallyworld_: It gets a resultset which gets precached persons from IDs.
[04:40] <wgrant> Try listifying it.
[04:40] <wgrant> StevenK: Working on it.
[04:40] <wgrant> A few more comments.
[04:40] <wallyworld_> wgrant: i didn't evaluate it. that may be what i'm missing. will try that, thanks
[04:40] <StevenK> We can't just delete ValidPersonCache?
[04:40] <wgrant> StevenK: I plan to achieve its demise within the year.
[04:40] <StevenK> For crimes against humanity
[04:41] <wgrant> For it is an abomination whose reign of terror must be stopped.
[04:43] <wallyworld_> wgrant: yes, that was the problem, thanks
[04:43] <wgrant> wallyworld_: Great.
[04:44] <wgrant> wallyworld_: I've fixed a few views that were doing the same thing.
[04:44] <wgrant> Over time
[04:44] <wgrant> Attempting to precache, but not actually doing anything of value.
[04:44] <wallyworld_> i can imagine
[04:44] <wgrant> StevenK: You have my +1 but with various comments.
[04:44]  * wallyworld_ is glad there was a query count test
[04:44] <wallyworld_> which failed so it did its job
[04:45] <wgrant> Yup
[04:46] <StevenK> wallyworld_: You can add lists together, you know, right?
[04:46] <StevenK> Rather than .insert(0, ...
[04:47] <wallyworld_> StevenK: the order is preserved?
[04:47] <wgrant> StevenK: ... says he who just used [2] :P
[04:47] <wgrant> But yes, I wouldn't use insert() as wallyworld has.
[04:47] <wgrant> Mostly because it's confusing doing it twice to get opposite order.
[04:47] <wallyworld_> StevenK: feel free to do a drive by in your branch so long as the ordering remains as expected
[04:48] <wgrant> StevenK: Are you looking at Colin's branch?
[04:48] <wgrant> If not, I will.
[04:48] <StevenK> wgrant: I have done, I'm happy with it, but given it's wide-reaching I wanted a second opinion.
[04:49] <wgrant> I don't see a review.
[04:49] <StevenK> https://code.launchpad.net/~cjwatson/launchpad/custom-upload-parsing/+merge/107656
[04:50] <wgrant> There's an MP, but no comments.
[04:50] <wgrant> Did it get eaten by longpoll?
[04:50] <StevenK> I haven't commented yet
[04:50] <StevenK> I can if you wish
[04:51] <wgrant> I shall fetch a drink and look over it.
[04:51]  * StevenK stabs longpoll more
[04:51] <wgrant> Hm
[04:51] <wgrant> MP diffs are a bit more readable with the excessive line-height disabled.
[04:52] <StevenK> wgrant: The portlet is not used for the edit form class, but BugView and BranchView, and they *don't* implement show_information_type_in_ui
[04:52] <wgrant> StevenK: Ah, indeed, I am stupid.
[04:52] <wgrant> StevenK: But they should implement that.
[04:52] <wgrant> It's only temporary, and it's going to be shorter to have it in the view classes.
[04:52] <wgrant> And less hideous.
[04:52] <StevenK> Just so it doesn't look utterly bonkers
[04:57] <StevenK> wgrant: The portlet is tested elsewhere in a doctest
[04:58] <wgrant> StevenK: Ah. That's what I would have expected if it was eg. Bugs, but I thought Code had a bit more sense than that.
[04:59] <StevenK> Clearly not
[05:00] <wgrant>  /win 3
[05:00] <wgrant> Bah
[05:01] <StevenK> wgrant: http://pastebin.ubuntu.com/1014208/
[05:03] <wgrant> StevenK: hat was that nbsp doing there? A leftover from the link that isn't there yet?
[05:04] <StevenK> wgrant: It was copied from the bugs template, so likely.
[05:04] <wgrant> Right. LGTM, then.
[05:04] <wgrant> Thanks.
[05:10] <wallyworld_> hurry up launchpad, scan my @!@$!% branch already
[05:11] <StevenK> wallyworld_: You used to be on the code team, fix the scanner.
[05:11]  * StevenK hides.
[05:11]  * wallyworld_ gets out flamethrower
[05:11]  * wallyworld_ blames thumper
[05:16] <StevenK> wallyworld_: Do you recall what AMI your ec2 runs this morning used?
[05:16] <wallyworld_> StevenK: 529 i am pretty sure
[05:16] <StevenK> That is excellent news.
[05:17] <wallyworld_> hmmm. i think this branch is stuck. 15 minutes and counting
[05:17] <wallyworld_> StevenK: yes, glad you fixed it
[05:18] <wallyworld_> ah, just completed
[05:18] <StevenK> wallyworld_: I'm still a bit unhappy that it took me until 1:10am to do so.
[05:19] <wallyworld_> StevenK: take the last hour or so of today off. have a beer :-)
[05:19] <StevenK> ENOBEER
[05:19] <wallyworld_> wine then :-)
[05:20] <StevenK> ENOWINE
[05:20] <StevenK> ENOALCOHOL
[05:22]  * StevenK gets tempted to fix ec2 images to not use $EMAIL
[05:22] <StevenK> Actually how does even *work*
[05:23] <wallyworld_> you have no alcohol in the house? shame
[05:23] <wallyworld_> what, is that a whip i can hear?
[05:32]  * StevenK stabs buildbot
[05:36] <wgrant> Usual bzr thing?
[05:36] <StevenK> No, my fault
[05:36] <wgrant> No
[05:36] <wgrant> This looks legit.
[05:36] <wgrant> Yeah
[05:37] <StevenK> I have a small fix
[05:42] <StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/testfix-no-builder-description/+merge/107913
[05:44] <wgrant> StevenK: If it works, ship it.
[05:44] <StevenK> wgrant: Did you look at cjwatson's MP?
[05:47] <wgrant> StevenK: Most of the way there. It's the sort of thing I'd tend to self-review just to avoid subjecting a reviewer to it.
[05:49] <StevenK> Yah, self-reviewed and landed
[05:49] <wgrant> No, I mean cjwatson's thing.
[05:49] <wgrant> But yes, yours was obviously self-reviewable :)
[05:50] <StevenK> Ah
[05:53] <wgrant> StevenK: It has my +1
[06:08] <StevenK> wgrant: Excellent
[06:51] <adeuring> good morning
[06:51] <adeuring> hi al-maisan
[06:51] <al-maisan> moin adeuring
[06:51] <al-maisan> how are things?
[07:00] <cjwatson> wgrant: Hmm.  I did initially try a classmethod for this custom upload rearrangement and it didn't seem to come out shaped very nicely; in particular I definitely found moving the target directory stuff out of __init__ to be a win (Jeroen suggested consolidating *AlreadyExists on the bug, and I never liked the way that it sometimes failed in the constructor and sometimes in process anyway)
[07:00] <cjwatson> But I can try again if you like, maybe with just the classmethod change but leaving __init__ as I currently have it?
[07:01] <wgrant> cjwatson: Mm, that's true, it could fail in setTargetDirectory if it's badly formatted. So maybe.
[07:02] <wgrant> Anyway, it's just a suggestion.
[08:18] <cjwatson> Could I have "Status: Approve" on https://code.launchpad.net/~cjwatson/launchpad/queue-api-accept-reject/+merge/107894 so I can land it?  It has a +1 review already.
[08:19] <StevenK> cjwatson: Sorry about that.
[08:19] <StevenK> cjwatson: Done.
[08:19] <cjwatson> NP, thanks
[08:19] <StevenK> Is scripts/ftpmaster-tools/queue dead yet? :-)
[08:20] <cjwatson> ... a bit of work left for that
[08:21] <StevenK> I know :-)
[08:32] <wgrant> cjwatson: You probably want to make QueueInconsistentStateError a 400 rather than an OOPS
[08:32] <wgrant> cjwatson: The browser code catches it and turns it into a non-OOPS error, but the API will default to OOPSing.
[08:34] <cjwatson> wgrant: Hm.  I've already started landing this.  Should I abort?
[08:34] <cjwatson> (I agree)
[08:35] <wgrant> cjwatson: No, the OOPS reports are shit enough already that nobody will notice.
[08:35] <wgrant> But a quick followup would be nice.
[08:35] <cjwatson> That said I didn't start ec2 land that long ago.  Probably more economical to kill it.
[08:35] <wgrant> Potentially.
[08:36]  * cjwatson does so.
[08:54] <cjwatson> wgrant: So http://bazaar.launchpad.net/~cjwatson/launchpad/queue-api-accept-reject/revision/15326 ?
[09:02] <jml> can someone please land this approved branch for me?
[09:02] <jml> https://code.launchpad.net/~jml/launchpad/archive-commercial-rename-support/+merge/107819
[09:02] <jml> hmm, wait, ec2 land works for me, I think.
[09:02] <jml> never mind.
[09:04] <wgrant> cjwatson: Looks good.
[09:07] <cjwatson> wgrant: Thanks.  Landing for real now.
[09:09] <wgrant> Great.
[09:10] <wgrant> Oh
[09:10] <wgrant> ECHAN
[10:08] <mgz> wgrant: from #launchpad, so what would be the steps if we couldn't get a branch owner to poke things themselves?
[10:08] <mgz> the same but a l-osa?
[10:10] <jml> mgz: there used to be a team that had write privs to all branches. I guess any administrator could still do that.
[10:12] <wgrant> mgz: Right, webops have write access to all branches.
[10:12] <wgrant> So they can carry out the same actions, and it's sometimes easier to do that than walk the user through it.
[10:16] <wgrant> It looks like the relevant commit was directly to trunk, so hopefully none of the stacked-on branches have a copy of the corruption.
[10:20] <StevenK> jml: That team (bazaar-experts) is long dead.
[10:41] <cjwatson> wgrant: I tweaked https://code.launchpad.net/~cjwatson/launchpad/custom-upload-parsing/+merge/107656 a bit; if that looks OK to you now, could I have "Status: Approved"?
[10:43] <wgrant> cjwatson: Thanks. Done.
[11:30] <wgrant> mgz: The example invocation in the script is out of date.
[11:30] <wgrant> mgz: The statement in the bug is correct.
[11:30] <wgrant> PPA stats have not been updating since the 21st.
[11:34] <mgz> wanted the guy the clarify the report
[11:34] <mgz> but if it's something you can just poke someone to fix, that's fine.
[11:34] <wgrant> A quick look at the crontabs shows that the script was disabled on the 21st due to germanium load issues.
[11:34] <wgrant> germanium is still insanely loaded, so it's possibly not a good idea to reenable it.
[11:39] <mgz> so... convert to question, say we know about the problem but it's not something being fixed right now?
[11:41] <czajkowski> or triage it high still and adda note about the scripts?
[11:41] <wgrant> Or bug IS to give germanium some minions.
[11:42] <mgz> still need to find a diagram of what box does what with launchpad
[11:42] <mgz> germanium is in charge of what exactly?
[11:43] <wgrant> carob:~stevenk/name-to-service is probably the best we have right now.
[11:43] <wgrant> germanium is ppa.launchpad.net
[11:43] <wgrant> It does everything relating to PPAs, except builds.
[11:44] <wgrant> (including serving PPA downloads to every PPA-using machine in the world)
[11:46] <elmo> there's a ticket about germanium frontends FWIW
[11:47] <wgrant> StevenK: Your list is missing bilimbi, btw.
[11:47] <wgrant> elmo: Yeah, but...
[11:48] <wgrant> StevenK: Also mcmurdo
[12:44] <noodles775> Hi! I've just setup an LP dev environment, but get the error "String or Integer object expected for key, unicode found" when trying to run a test - http://paste.ubuntu.com/1014687/
[12:44] <noodles775> Any pointers as to what I've missed?
[12:44] <jml> Hmm.
[12:44] <jml> That looks very familiar.
[12:45] <jml> noodles775: that's a testr bug.
[12:45] <jml> noodles775: the failure is related to the dirdbm (or whatever) db that itt uses.
[12:45] <noodles775> Thanks jml - I'll just run the tests old-skool then :)
[12:46] <jml> noodles775: np.
[12:54] <noodles775> jml, achuni: an alternative for large htpasswd files: http://stackoverflow.com/questions/6590789/linux-htpasswd-file-too-big-more-than-2000-users
[12:55] <noodles775> (again, may or may not be relevant depending on the measurements, but looks likely that it will be :) ).
[12:56] <jml> that would be a GET-time issue rather than a .htaccess-generation-time issue. still relevant though.
[13:12] <mgz> gmb: on subunit and avoiding stream breakage from other things mixing in
[13:12] <mgz> what bzr does is use a dedicated pipe, avoiding most of that pain
[13:12] <mgz> might not be simple with indirection through zope.testing but is much safer than messing with the process std streams
[13:13] <gmb> mgz: Ah, thanks for the heads-up. That might make more sense, assuming we can untangle how that interacts with the parallelisation story.
[13:14] <mgz> right, in bzr it's simple because we do the fork ourselves,
[13:14] <mgz> multiple packages make that a bit more of a juggling act though
[13:40] <cjwatson> jml: I think I'm going to plagiarise your foul column renaming hack.
[13:40] <jml> cjwatson: best of luck.
[13:45] <jml> that reminds me
[13:45] <jml> the example I cribbed from has a bug, I think.
[13:46] <cjwatson> oh?
[13:47] <jml> nothing relevant for us, I don't think
[13:51] <jml> cjwatson: SourcePackageRelease sets 'copyright' to the default Python copyright even if it's not provided
[13:53] <cjwatson> That's only due to copyright being a builtin, yes?
[13:53] <jml> yeaah
[13:53] <jml> otherwise it would be a NameError
[13:53] <cjwatson> Although I thought we used -S
[13:54] <jml> oh, we do.
[13:54] <cjwatson> So NameError
[13:54] <jml> Right.
[13:55] <cjwatson> Though do we?  If you run bin/py on its own, you get a copyright builtin.
[13:55] <cjwatson> Because even though its #! line has -S, it re-execs python.
[13:55] <cjwatson> But I guess bin/run uses -S in #! too.
[14:00] <jml> it's also difficult to grep for code that creates one
[14:26] <tedg> Hey, with the new privacy work going on will that allow blueprints to be private?
[14:43] <jml> what invalidates a token?
[15:07] <flacoste> mrevell: are we having the work items checkpoint?
[15:08] <noodles775> jml: a setting the date-deactivated, let me check the details.
[15:08] <jml> noodles775: I think it's unsubscribing someone who has an active token
[15:09] <noodles775> abentley: time for a review? https://code.launchpad.net/~michael.nelson/launchpad/982938-dont-load-all-tokens-for-all-ppas-into-memory/+merge/107980
[15:09] <abentley> noodles775: Be with you in a minute.
[15:14] <noodles775> jml: setting ArchiveAuthToken.date_deactivated (see soyuz/model/archiveauthtoken.py:58 for the helper method, but it can also be done via the API with the right privs).
[15:22] <abentley> noodles775: looking...
[15:22] <noodles775> Thanks abentley :)
[15:23] <abentley> noodles775: It looks like you are not certain this change will help.
[15:24] <abentley> noodles775: Why not do it all in a single query?
[15:24] <noodles775> abentley: some private PPAs have *lots* of tokens...
[15:26] <noodles775> abentley: normally in any 5minute period, there will be only a number of PPAs affected, so doing one extra query per PPA seems reasonable to loading those tokens into memory (in a dict)
[15:27] <abentley> Right.  I'm asking about 1 query vs many queries, not about many queries vs dict.
[15:28] <noodles775> abentley: Ah, I see. So one query to get a resultset of all the tokens, and if it was ordered by PPA id, we could potentially iterate that...
[15:29] <abentley> noodles775: right.
[15:29] <noodles775> abentley: let me try.
[15:29] <abentley> noodles775: One way would be nested generators.
[15:32] <abentley> noodles775: Though it's probably easier to handle it in the final loop.
[15:36] <abentley> noodles775: Something like this for the query? http://pastebin.ubuntu.com/1014950/
[15:38] <noodles775> abentley: ah, getting a tuple of (archive, tokens) will be much simpler than iterating based on an ordered result set... thanks!
[15:41] <abentley> noodles775: np
[15:41] <abentley> noodles775: If it works out, you could also test the query count.
[16:07] <noodles775> abentley: I don't see a way I can do that without needing to create an in-memory list of tokens for a PPA (ie. it's no longer a result-set of tokens).
[16:08] <abentley> noodles775: Fair enough.
[16:09] <noodles775> abentley: but I also fonud another spot where the result-set of tokens will be used in memory (it's sorted in another function...)
[16:09] <noodles775> abentley: I'm just seeing if I can fix that.
[16:09] <abentley> noodles775: r=me
[16:10] <noodles775> abentley: Thanks, but can you hold off on approving until I check this other spot where it'll turn the result set into an in-memory list?
[16:10] <abentley> noodles775: okay.
[16:35] <noodles775> abentley: I've pushed up some extra revs (15331..15333) which remove one place where the tokens were sorted in memory, instead sorting them in storm.
[16:38] <abentley> noodles775: Looks good.  r=me
[16:39] <abentley> noodles775: I wonder whether you could get the behaviour you want (loop by ppa, then tokens) using itertools.groupby
[16:53] <noodles775> Thanks abentley. re. itertools.groupby, I think it would be possible, but would require quite a refactor as htpasswd_credentials_for_archive() currently assumes it'll be passed just the tokens for the one archive.
[16:54] <noodles775> abentley: and (really sorry) I've just noticed that after the last refactor you just checked, I can remove _getValidTokensForPPAs completely now, afaics... checking.
[17:05] <noodles775> abentley: so, r15334 removes the now unecessary _getValidTokensForPPAs.
[17:05]  * noodles775 updates the test instructions.
[17:11] <noodles775> abentley: sorry for the incremental realisations there, but I believe that's it :) I need to run, but will check back later in case you've any issues with the recent revisions. Thanks for all your help!
[17:11] <noodles775> abentley: and if you are happy with it as is, can you please set the status to approved? Thanks.
[17:13] <jml> why does getNewPrivatePPAs work from the date_completed of the last successful script run, rather than date_started?
[17:13] <jml> getNewTokensSinceLastRun works from date_started
[17:14] <abentley> noodles775: r=me
[17:14] <noodles775> jml: I could only assume that one of them was updated due to a bug, and teh other was missed.
[17:15] <noodles775> Thanks abentley - do you send it off to test and land? I've got tests running on my dev instance anyway to be sure myself.
[17:15] <jml> correct code is so much easier to understand
[17:15] <abentley> noodles775: I can do that.
[17:15] <noodles775> Great, thanks again.
[17:18] <jml> noodles775: oh hey, it was you that fixed that bug :)
[17:18]  * jml discovers https://bugs.launchpad.net/launchpad/+bug/628711 
[17:18] <_mup_> Bug #628711: generate-ppa-htaccess is too slow <lp-soyuz> <p3a> <ppa> <qa-ok> <software-center> <Launchpad itself:Fix Released by michael.nelson> < https://launchpad.net/bugs/628711 >
[18:13] <czajkowski> sinzui: are you about ?
[18:13] <sinzui> I am
[18:14] <czajkowski> sinzui: having some issues when I renamed a project stuff hasn't followed through
[18:14] <czajkowski> sinzui: https://answers.launchpad.net/launchpad/+question/198320
[18:15] <sinzui> czajkowski, Looks like you did rename it? What has not happened?
[18:16] <czajkowski> bugs from old project name have not been migrated over
[18:16] <czajkowski> it;s old name is still being displayed on parent project page
[18:16] <sinzui> that is memcached
[18:16] <czajkowski> sinzui: and on top of bugs/blueprints its still referred to as old name
[18:16] <sinzui> The project listing is expensive. It takes 1-3 hours to clear I think
[18:17] <czajkowski> it was done on the 28th
[18:17] <sinzui> czajkowski, the other displaynames you mention can only be changed by the project maintainer
[18:18] <sinzui> only jonobacon can change the display name that the pages show. You can change the Launchpad Id.
[18:19] <sinzui> czajkowski, tell jono to visit https://launchpad.net/ubuntu-accomplishments-web/+edit update his project
[18:19] <czajkowski> sinzui: thanks
[18:20] <czajkowski> sinzui: and the bugs issue? will resolve
[18:20] <czajkowski> ?
[18:20] <sinzui> that is right. bugs and blueprints are doing exactly what jono said he wanted
[18:21] <sinzui> czajkowski, but remember that the projects listed on the project group page are cached for a few hours
[18:21] <czajkowski> sinzui: thanks thought I was going crazy
[18:22] <sinzui> czajkowski, we have a very old bug asking us to change name => launchpad_id and displayname => name so it is clear about what is changing
[19:26] <jam> bigjools, deryck, flacoste, gary_poster, jam, lifeless, mrevell, sinzui team lead meeting in 5 minutes, hopefully I set it up correctly: https://plus.google.com/hangouts/_/495930018d0f18610dd093d77c49542be643d0e5#
[19:27] <jelmer> jam: it's a good thing you reminded jam about it ;)
[19:27] <jam> jelmer: I didn't want to forget
[19:27] <jam> its a copy paste, I didn't feel like editing anything
[19:27] <jelmer> I suspected it was something like that, just teasing :)
[19:27]  * jelmer gets back to reviewing
[19:47] <noodles775> Hrm, while running all LP tests on a precise instance, I get lots of errors like "TypeError: getresponse() got an unexpected keyword argument 'buffering'" (http://paste.ubuntu.com/1015322/). Is this something I can fix on my instance, or does it need to be a certain python version/distroseries?
[19:47]  * noodles775 checks dev.launchpad.net again...
[19:49] <lifeless> noodles775: LP *should* run in precise, but is only *validated* to run on Lucid.
[19:49] <lifeless> noodles775: https://dev.launchpad.net/Running/LXC
[19:50] <noodles775> Thanks lifeless
[19:51] <lifeless> we're still running python2.6 in production
[21:41] <sinzui> wallyworld_, ping
[21:41] <wallyworld_> sinzui: hi
[21:42] <sinzui> wallyworld_, I thought the widget required an element with editicon as a class. I suppose not since you tested it in two browsers to verify it renderered
[21:43] <james_w> does someone have a few minutes to review https://code.launchpad.net/~james-w/launchpad/drop-filecmp/+merge/108021 please?
[21:43] <wallyworld_> sinzui: yes, it appears to work fine. but i do recall the editicon requirement. i will check the choiceesource code to see what it's doing
[21:43]  * sinzui is looking too
[21:44] <sinzui> wallyworld_, isn't it needed by the spinner..which might not be an issue with enums
[21:44] <wallyworld_> could be, still looking
[21:45] <jml> james_w: lgtm :)
[21:46] <james_w> :-)
[21:46] <wallyworld_> sinzui: the editing works because clickable_content is true
[21:49] <wallyworld_> sinzui: yes, because no patch plugin is used since it's not going to the server etc, the editicon is not required
[21:50] <wallyworld_> but i could add that class to the anchor is suppose
[21:51] <sinzui> okay, thank you. r=me
[21:51] <sinzui> wallyworld_, I don't like the editicon since it is not ever clear what the element has to be and when it is used
[21:52] <wallyworld_> yeah
[22:02] <sinzui> wallyworld_, wgrant, StevenK, jcsackett, Should we do something about this bug? https://bugs.launchpad.net/launchpad/+bug/246964
[22:02] <_mup_> Bug #246964: The new privacy/security portlet should use lock icons <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/246964 >
[22:02] <lifeless> wallyworld_: whasts the status with rev 15325
[22:03] <wallyworld_> lifeless: rollback branch landed
[22:03] <lifeless> wallyworld_: in  buildbot at the moment ?
[22:03] <wallyworld_> lifeless: no, bb still has 4 hours to run before it picks up my landing
[22:03] <lifeless> ok
[22:03] <lifeless> we have a near-critical situation with software centre
[22:03] <wallyworld_> lifeless: when will the new work make bb run faster? soon i hope :-)
[22:04] <lifeless> hardware has been requested for that
[22:04] <lifeless> we're expecting 30m runtimes
[22:04] <wallyworld_> yay
[22:04] <lifeless> so we may end up fiddling with the landing pipeline over the next 15-24 hours
[22:04] <lifeless> just a headsup, for details see -ops
[22:06] <lifeless> who has access to qa http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/15323 ? I'm guessing web ops and soyuzy folk only?
[22:09] <lifeless> wallyworld_: could I impose o you to qa 15327 - information_type in the branch UI if a feature flag is set.
[22:10] <wallyworld_> lifeless: no problem. we're in a standup now, can it wait till after that?
[22:10] <jml> meetings!
[22:10] <lifeless> wallyworld_: sure thing
[22:10] <wallyworld_> ok
[22:10] <lifeless> just smoothing the path for this mini-crisis
[22:11] <wallyworld_> lifeless: so, i didn't grok fully from scanning -ops how lp landings are connected to a software centre issue
[23:02] <lifeless> oh foo
[23:02] <lifeless> my landing setup is bong
[23:02] <lifeless> wallyworld_: can you lp-land a branch for me ?
[23:03] <lifeless> https://code.launchpad.net/~lifeless/launchpad/generate-htaccess-speed/+merge/108074
[23:03] <wallyworld_> lifeless: sure
[23:03] <lifeless> my lp-land setup is still broken and this is time sensitive
[23:03] <lifeless> need it in the buildbot run
[23:03] <wallyworld_> lifeless: justing finishing the standup  now. will do it in 3 minutes and 23 seconds
[23:04] <jcsackett>  the 23 seconds tells you he's serious.
[23:06] <lifeless> wallyworld_: thank
[23:06] <lifeless> wallyworld_: I have to go for my monthly allergy shot now
[23:06] <wallyworld_> lifeless: np. being done was we speak
[23:07] <lifeless> wallyworld_: I probably won't be back until the buildbot run has started, so I'm going to hand off the entire 'get it landed' bit to you :) - if it doesn't work *and* you need my input to correct it please ring my nz mobile (in the directory)
[23:08] <wallyworld_> will do. enjoy you alergy shot :-)
[23:08] <lifeless> thanks
[23:54] <mwhudson> lifeless: i presume you've seen http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed already?