[03:32] <mwhudson> thumper: can you look at https://code.edge.launchpad.net/~mwhudson/launchpad/vostok-traverse-distro/+merge/31241 again?
[03:32] <thumper> ok
[03:32] <thumper> mwhudson: do you have a few minutes for me to bounce some stuff off you?
[03:32] <thumper> skype like?
[03:33] <mwhudson> thumper: ok
[03:34] <mwhudson> thumper: i'm online
[03:35] <thumper> mwhudson: I'll have to defer for now, other people calling
[03:35] <mwhudson> thumper: ok
[03:36] <mwhudson> thumper: the call or the review or both?
[03:36] <thumper> the call
[03:36] <mwhudson> k
[05:56] <mwhudson> thumper: NotFound is a zope thing
[05:56] <mwhudson> it's not in lp.app.errors
[05:56] <mwhudson> so i'm going to ignore that comment?
[06:03] <thumper> um...
[06:05] <mwhudson> thumper: NotFound != NotFoundError
[06:05] <thumper> ah
[06:05] <thumper> yeah
[06:05] <thumper> I just worked that out
[06:05] <mwhudson> for better or worse
[06:06] <thumper> ok
[06:06] <mwhudson> something inside traversal converts the latter into the former
[06:06] <mwhudson> cool
[07:23] <henninge> jtv: Why do you want to cache the incumbent message in the traits helper?
[07:23]  * henninge is back to business ;)
[07:23] <lifeless> hi henninge
[07:23] <jtv> henninge: good!  :)
[07:24] <henninge> Hi lifeless! ;)
[07:24] <henninge> jtv: I am starting to see what Danilo meant by "heavy weight".
[07:25] <jtv> henninge: those are the helpers, and as I said, those are a bit legacy in that they may not be needed any more.
[07:25] <jtv> That's not the traits; it's what I extracted the traits out of.
[07:25] <henninge> jtv: I understand but I would have expected that to go into the class that uses the traits.
[07:25] <jtv> henninge: can't do that in the class that uses the traits.
[07:26] <henninge> do what, the caching?
[07:26] <jtv> The class that uses the traits can be a model class—not good to cache this sort of thing there.
[07:26] <jtv> We can do it in the code.
[07:26] <henninge>  ok
[07:27] <jtv> But as I said, this is just what's left after extracting the traits—the caching is the possible reason not to remove the helpers entirely once we have the traits.
[07:27] <lifeless> do you guys know much about the API export stuff?
[07:27] <jtv> And I'm not saying we need the caching, just that it's an appropriate and convenient place for it if we do.
[07:27] <jtv> lifeless: not that much
[07:27] <henninge> I see
[07:28] <jtv> henninge: cleaning up the helpers is a possible next step, but the branch was big enough.  :)
[07:28] <henninge> Okay, so other users of the traits are not expected create helper classes, too?
[07:28] <jtv> henninge: no, not at all
[07:29] <jtv> As I explained yesterday: one class does it all, and the existence of an older helper class that I extracted them out of is merely a distraction in all this.
[07:29] <jtv> Look at the actual TranslationSideTraits class: is that heavyweight?
[07:30] <henninge> jtv: no, except ...
[07:30] <henninge> ;)
[07:30] <henninge> getCurrentMessage
[07:31] <jtv> The implementation is a bit daft because of the transient mess with getImportedTranslationMessage and getCurrentTranslationMessage.  I'd prefer to replace the "if" with separate methods.
[07:32] <jtv> But that's all under the hood.
[07:34] <henninge> jtv: which "if" ?
[07:35] <jtv> henninge: inside getCurrentMessage… that's not what you meant?
[07:35] <henninge> sorry, yes.
[07:37] <henninge> jtv: Although I was wondering if a specific method like that belongs into the traits at all ...
[07:37] <jtv> If we had all queries stormified and available from the interfaces, then no.  But in the real world it's a primitive.
[07:38] <henninge> jtv: what do you bean by "available from the interfaces"?
[07:39] <jtv> The interfaces underneath wherever we need this.
[07:39] <henninge> Sorry for being pita about this but I want to make sure I understand why I am on your side with this ... ;-)
[07:39] <jtv> No worries.  It's good.
[07:40] <jtv> What I mean is, sometimes we'll need to ask for the current message for a given potmsgset, template & language on a given side.
[07:40] <jtv> If we could just return a Storm object for the right condition, then getFlag(TranslationMessage) would probably do the trick.
[07:41] <jtv> Of course we could also do that and go straight to Storm to ask for the current message, but that seems a bit messy.
[07:43] <henninge> jtv: You lost me on the last sentence
[07:43] <henninge> And you literally mean "getFlag(TranslationMessage)"?
[07:44] <henninge> I mean, on the class.
[07:44] <jtv> I mean: we could probably do without getCurrentMessage if we were willing to do something like Store.of(TranslationMessage).find(traits.getFlag(TranslationMessage)).one()
[07:44] <jtv> Yes
[07:44] <henninge> jtv: is there another class that will have the flags?
[07:45] <jtv> Yes, there might be a ClassAlias in Storm.
[07:45] <henninge> I'd like to see Store.of(TranslationMessage).find(traits.current_flag).one()
[07:45] <henninge> Oh
[07:45] <jtv> Well what you just said is actually a very good way to formulate it.
[07:46] <lifeless> as long as its not one per-row-per-page :)
[07:46] <jtv> *If* we only have the one class, of course
[07:47] <henninge> jtv: I'd provide both.
[07:47] <henninge> a "current_flag" attribute for most use cases
[07:47] <henninge> and a "getCurrentFlag(cls)" for the alias case.
[07:48] <jtv> lifeless: maybe you know this one...  I just evaluated TranslationMessage.is_current_ubuntu and ubuntu_traits.getFlag(TranslationMessage).  They both return the same PropertyColumn object.  Yet a Storm query will work with the former and not with the latter.
[07:48] <henninge> oh, it does not?
[07:48] <lifeless> so the former is a class attribute
[07:48] <jtv> Yes
[07:48] <lifeless> is the latter perhaps returned a securityproxied object?
[07:49] <jtv> I think the __repr__ would have told me… in both cases it says:
[07:49] <jtv> <storm.properties.PropertyColumn object at 0xbcc7b3c>
[07:49] <jtv> But there must be _something_ with proxies, because the error says:
[07:49] <jtv> CompileError: Don't know how to compile type zope.security._proxy._Proxy of <storm.expr.Eq object at 0xc332fac>
[07:49] <lifeless> ahha yes
[07:49] <lifeless> :)
[07:50] <lifeless> print dir(thing), and thing.__class__
[07:50] <jtv> Heh... if I removeSecurityProxy then the query does work.  Madness reigns.
[07:51] <henninge> jtv: no, it does not
[07:51] <jtv> lifeless: the __class__ are the same for both
[07:51] <lifeless> thats interesting
[07:51] <henninge> it's because you regeistered TranslationSideTraitsSet as a securedutility.
[07:51] <henninge> "does not" referred to madness reigning, btw.
[07:51] <jtv> henninge: okay, but then why don't I see the proxy?
[07:52] <jtv> Right, took me a while to figure that out :)
[07:52] <henninge> jtv: that's waht proxies do. They pretend to be the real thing.
[07:52] <jtv> Okay, but this is an incredibly effective pretense!
[07:53] <jtv> At least, I had a memory of the proxies showing up when I printed objects in "make harness"
[07:53] <jtv> But yes, dir() exposes the difference.
[07:55] <henninge> jtv: another thing I wonder about it "other_side"
[07:56] <jtv> henninge: would you prefer something like "other_side_traits"?
[07:56] <jtv> Or would you prefer it to be a TranslationSide that you'd use to look up the traits?
[07:57] <henninge> jtv: no, I don't wonder. ;)
[07:57] <henninge> anymore
[07:57] <jtv> oh ok :)
[07:57] <henninge> jtv: but "other_side_traits" seems preferable.
[07:57] <jtv> OK
[07:57] <henninge> My wondering was about it not being set but I saw that it happens in TranslationSideTraitsSet.__init__.
[07:57] <henninge> That's good.
[08:19] <jtv> henninge: I renamed other_side and also removed MessageSideHelper.getFlag (because that code moved to the traits in its entirety)
[08:39] <henninge> jtv: all the calls to "removeSecurityProxy" in your test - are they a result of abel's work?
[08:39] <jtv> henninge: it's not unthinkable that they contributed, but the main thing is as in the cover letter: using Zope in tests that didn't use it before.
[08:40] <jtv> Sorry: it's not unthinkable that *it* contributed.
[08:40] <henninge> 653	         external_template = self.factory.makePOTemplate()
[08:40] <henninge> 654	-        external_template.productseries.product.official_rosetta = True
[08:40] <henninge> 655	+        product = external_template.productseries.product
[08:40] <henninge> 656	+        removeSecurityProxy(product).official_rosetta = True
[08:41] <henninge> jtv: how is zope involved here that was no before?
[08:42] <henninge> And I wonder why "official_rosetta" is not settable in the first place ...
[08:42] <jtv> henninge: layer change
[08:42] <henninge> Oh, I did not know that affected how the factory creates objects.
[08:43] <jtv> AIUI it doesn't, directly, but it means no proxies.
[08:44] <jtv> Correction again: running Zopelessly means no proxies.
[09:49] <henninge> jtv: why is "test_getFlag_and_setFlag" one test?
[09:50] <jtv> henninge: because it tests consistency between the two, more than either one of them specifically.  Not very imaginative, sorry.
[09:50] <henninge> jtv: ok, I see it now.
[09:50] <jtv> (There are two separate tests in the concrete test classes that tie the internal consistency of the traits to the reality of the two flags)
[09:51]  * jtv tries DSL again…
[10:00] <jtv> Well that was disappointing.  Still no DSL.  Wonder if a bill got lost again.
[10:13] <stub> https://code.edge.launchpad.net/~stub/launchpad/cronscripts/+merge/31934
[10:14] <stub> adeuring: ^^
[10:14] <adeuring> stub: sure; let me just finish a review for james_w
[10:59] <jtv> henninge: thanks!
[10:59] <henninge> jtv: welcome
[11:00] <henninge> you were gone to check DSL when I wanted to tell you. Is it working again now??
[11:00] <jtv> henninge: nope
[11:08] <adeuring> stub: r=me
[11:21] <stub> ta
[11:24] <jtv> henninge: can't lend using edge…  I'll try again.
[12:23] <jml> james_w, I'll take a look at your no-more-sampledata-2 branch.
[12:23] <jml> (next week, I'm going to do less coding stuff, promise)
[12:40] <bac> morning adeuring
[12:40] <adeuring> hi bac!
[12:41] <bac> adeuring: many takers today?
[12:41] <adeuring> bac: a few. Could be worse ;)
[12:52] <bac> jml: can you do a db review if i don't get it done before stub goes EOD?
[13:09] <james_w> thanks adeuring and jml
[13:13] <jml> bac, sure.
[13:29] <jml> james_w, done!
[13:32] <james_w> jml: did you get bored? :-)
[13:33] <jml> james_w, not so much bored as struck with a desire to come up with many ways of saying the same thing :)
[14:03] <adeuring> james_w: r=me for another branch, again one minor nitpick ;)
[14:03] <james_w> adeuring: thanks, though the last one wasn't so minor :-)
[14:04] <james_w> adeuring: I thought the same thing about isinstance, but the test proved me wrong. Maybe something needs to be imported for the monkeypatch to happen?
[14:06] <adeuring> james_w: interesting that you need to remove the proxy: IIRC zope.security.porxy or somesuch directly changes the built in isinstance function.
[14:06] <adeuring> But anyway, if you must remove the proxy, then be it so. But perhaps gary_poster knows a bit more?
[14:07] <gary_poster> no, isinstance is not modified
[14:07] <james_w> jml said that you can "from zope.security.proxy import isinstance as zope_isinstance"
[14:07] <gary_poster> it's not called that
[14:08] <jml> gary_poster, we have code in Launchpad that does exactly that.
[14:08] <gary_poster> at least I don't think so (and I use the one from zope.proxy)
[14:08] <adeuring> gary_poster: thanks -- seems that I am somewhat confused...
[14:08] <gary_poster> but that's the right idea
[14:08] <gary_poster> ok, jml, fair enough.  that's certainly the right idea, as I said.  zope.proxy has the more general functions with which I am more familiar
[14:09] <jml> gary_poster, more general functions sounds like a good idea :)
[14:12] <gary_poster> :-) well, looks like my memory is just faulty.  The general functions are there that work with the core proxy stuff, but there's not a direct isinstance equivalent.  (Available functions are listed in eggs/zope.proxy-3.5.0-py2.6-linux-x86_64.egg/zope/proxy/interfaces.py fwiw)
[14:13] <gary_poster> a function called "zope_isinstance" offends my naming sensibilities ;-)
[14:13] <adeuring> so, importing from zope.security.proxy would be the roght way?
[14:13] <gary_poster> yes, adeuring
[14:13] <gary_poster> sorry for being confusing
[14:53] <james_w> adeuring: hello again, could I get an incremental review of https://code.edge.launchpad.net/~james-w/launchpad/soyuz-factory-improvements/+merge/31890 ?
[14:53] <adeuring> james_w: sure
[14:53] <james_w> oh, conflicts, I need to merge devel
[15:05] <james_w> done
[15:05]  * adeuring pulls the latest version
[15:21] <bac> jml: can you do a db review for https://code.edge.launchpad.net/~bac/launchpad/db-bug-613442/+merge/31955 ?
[15:22] <jml> bac, sure, after this call.
[15:22] <bac> thx
[15:25] <adeuring> james_w: again r=me. nice work!
[15:25] <james_w> adeuring: thanks
[15:45] <jml> bac, approved.
[15:45] <bac> thanks jml
[15:58] <bac> adeuring: may i get a code review for https://code.edge.launchpad.net/~bac/launchpad/db-bug-613442/+merge/31955 ?
[15:58] <adeuring> bac: sure
[15:58] <bac> thanks
[16:17] <adeuring> bac: why didn't you add a column for bug tracking?
[16:17] <adeuring> (and for code hosting, for projects)
[16:18] <bac> adeuring: bug tracking and code hosting can be properly derived from other pillar data.
[16:18] <bac> adeuring: it is better to have a derived attribute than a column in the db that may become out of sync
[16:19] <adeuring> bac: what about "bugs are tracked elsewhere"?
[16:19] <bac> adeuring: that would be indicated by having an external bug tracker noted
[16:20] <bac> adeuring: this email thread lays out much of the thinking, dense as it is: https://lists.launchpad.net/launchpad-dev/msg03952.html
[16:20] <adeuring> bac: Ah, right. And these is at present no need to indicate this in the comuted attribute?
[16:20] <bac> adeuring: i don't understand your question.
[16:20] <adeuring> sorry, my usual typing problems...
[16:21] <adeuring> bac: shouldn't the value "bugs are tracked elsewhere" being returned by bug_tracking_usage? (for porjects which do that)
[16:22] <adeuring> gah, that's done
[16:22] <adeuring> sorry, I was reading the diff for distros...
[16:23]  * adeuring should read the entire diff before asking pointless questions...
[16:26] <adeuring> bac: r=me
[16:27] <bac> thanks abel
[16:34] <EdwinGrubbs> jelmer_: do you have time to answer some of my questions on the branch you're reviewing?
[16:42] <jelmer_> EdwinGrubbs, sure
[16:43] <jelmer_> EdwinGrubbs: I don't see a followup from you after my last reply
[16:43] <EdwinGrubbs> jelmer_: oh, sorry, I didn't see your reply before.
[17:35] <bac> jml: you approved the db review of my branch.  what should i do about patch number?  next sequential?  how do i know there is no conflict?
[17:35] <bac> jml: i assume stub has a Big Chief Tablet where he coordinates the numbering
[17:53] <jml> bac, I don't have answers to any of your questions, I'm afraid :(
[17:54] <bac> jml: well i'll pick the next and cross my fingers.  (after looking at the unlanded MPs first)
[17:55] <jml> bac, that seems like the best approach
[17:55] <sinzui> bac: I have a branch that move the registration slot.
[17:56] <bac> sinzui: ok
[17:56] <bac> sinzui: are you going to get a UI review too?
[18:00] <sinzui> I was hoping rockstar could look at the picture and say this is agreeable to him, me, and henninge
[18:00]  * rockstar looks up
[18:01] <rockstar> sinzui, what picture?
[18:02] <sinzui> rockstar, the picture listed in https://code.launchpad.net/~sinzui/launchpad/launchpad-header-1/+merge/31975
[18:04] <rockstar> sinzui, ui=rockstar
[18:04] <rockstar> sinzui, I still hate that we feel that should go at the top of the page.
[18:05] <sinzui> yes. Maybe I will take a week off and write an alt-css that allows launchpad to get that non-sense out of the way
[18:09] <benji> speaking of, is there any way to remove the "Registered by" slot for a project?  Every time I visit the page for my little project Manuel I'm slightly jarred by the fact that it says "Registered 2010-01-13 by Björn Tillenius"
[18:09] <benji> (he registered it to work on some branches for Manuel before I used LP)
[18:13] <bac> sinzui: r=bac
[18:13] <sinzui> thanks bac. thanks rockstar
[18:14] <bac> benji: no.  why do you find it objectionable?  it is a true statement.
[18:14] <rockstar> benji, no, and that's why I think it should just go away.  It can be misleading.
[18:15] <rockstar> bac, it's a true statement, yes.  But it's almost worthless to put right at the top.
[18:15] <benji> bac: it's strange (or misleading as rockstar says); it's odd to place such an unimportant bit of information in such a prominant place
[18:16]  * benji assigns rockstar as his spokesman on this topic.
[18:16] <rockstar> bac, it has some useful information sometimes, but it's not information that should go at the top.
[18:17] <benji> I can only assume that it was done that way initially to reward people for registering projects in LP, but I think we're beyond that now.
[18:17] <sinzui> I look at who registered a project, bug, question, and mirror every day. It is not important, but it is information users actually want to know
[18:17] <rockstar> In most cases, the registrant is the same as the owner.  In other cases, it's just misleading.  In a few cases, you actually need to know it.  Those people can go hunting on the page for it.
[18:18] <sinzui> Not that you can so anything about someone who reports a bug that launchpad causes flatulence in donkeys
[18:18] <benji> bug, question, and mirror make sense to me, but it's not really that interesting to know that I registered the Firefox project if I don't really have anything to do with the project itself
[18:19]  * benji goes looking for high-profile projects that aren't yet represented in LP in a "Registered by" landgrab.
[18:20] <sinzui> If you are looking for missing upstream information, the registrant is one of the people you want to contact
[18:20] <sinzui> Most projects are missing information about upstream services
[18:22] <benji> oh, don't get me wrong, I think the information should be recorded and visible, but I don't see why regiterer should be more prominent than homepage, owner, driver, etc.
[18:23] <bac> rockstar: i updated to PG8.4 so i could cleanly make new sample data.  by the time i got ready to do it, there was a new version...made with 8.3.  i give up
[18:24] <rockstar> bac, you should blame on that and see who did that.
[18:26] <bac> is it me, or is PG8.4 much slower for 'make schema'?
[18:26] <sinzui> benji, I think  we all agree. The heading was design by canonical's design team to address the need of projects and people to see their identity prominently as a means to encourage adoption
[18:26]  * sinzui did not ask for permission to change the header
[18:35] <sinzui> benji, I disabled about 5000 projects that were not appropriate. Most land grabs last a few hours
[18:43] <jelmer_> sinzui: wow, 5000? That's quite a few.
[18:48] <sinzui> I have these numbers because I started writing a summary of project review. What you need to know is that I temporarily exceeded your record for linking projects to packages
[19:00] <jelmer_> sinzui: ah, thanks
[19:43] <deryck> Hi, bac.  I have an easy one-line change to versions.cfg for your review, if I may get in line.
[19:44] <bac> sure
[19:44] <deryck> thanks, bac!  The diff is large because I'm also re-enabling some reverted work.  All that is new is the change to versions.cfg in the diff.
[19:44] <deryck> https://code.edge.launchpad.net/~deryck/launchpad/update-storm-17-add-back-dupe-changes/+merge/31983
[19:44] <bac> sinzui: your name in the queue was leftover, right.  you have nothing outstanding for review?
[19:45] <sinzui> right, but I will add it back in 30 minutes
[19:45] <bac> deryck:  one line or 1296 lines?
[19:45] <bac> deryck: which one of those lines do you want reviewed?
[19:45] <bac> should i just pick one?
[19:46] <bac> i approve of line 157.  it is poetry.  r=bac
[19:46] <benji> lol
[19:47] <deryck> bac, the change at line 1293 of the diff is all that is new.  I'm just being lazy and adding back previous work that was reverted as I update the version of Storm.
[19:47] <deryck> heh
[19:49] <deryck> bac, I noted the actual line in scrollback if you really didn't see.  Line 1293. :-)
[19:49] <bac> deryck: wow.  ok, it looks fine given that explanation.
[19:49] <deryck> bac, great, thanks.
[21:07] <sinzui> bac: do you have time for a cache fix: https://code.edge.launchpad.net/~sinzui/launchpad/registry-cache-4/+merge/31998
[21:07] <bac> sinzui: sure
[21:08] <sinzui> bac I see a bad comment. in the second test. I wait for you challenge to make it a sensible comment
[21:11] <sinzui> bugger, I lost my bug id to
[21:12] <bac> sinzui: so line 51 should be miss.  is that what you're referring to?
[21:12] <sinzui> yes
[21:12] <bac> with that change it looks fine to me
[21:12] <bac> r=festus
[21:13] <sinzui> thanls
[21:13] <bac> any gunsmoke fans in the house?
[21:13] <sinzui> thanks bac
[21:23] <benji> bac: I would have gotten the reference if you'd picked any other popular US series from the 70s; not into Gunsmoke
[21:24]  * benji has a sudden desire to watch The Rockford Files.
[21:40] <bac> benji: "Who was Micah" for 20 points?
[21:40] <benji> I think I need to phone a friend
[21:42] <bac> no "Gunsmoke" or "The Rifleman"?
[21:42] <bac> Hoss Cartwright?
[21:42] <bac> Joe Friday?
[21:43] <benji> not really into westerns
[21:43] <benji> I'm down with Joe Friday; my son would vote for Reed and Malloy (Adam 12)
[21:44] <bac> for some reason i preferred "Emergency!"
[21:49] <benji> I tend to favor comedies from the 70s, most of the "action" series are pretty slow and linear by today's standards.
[23:09] <bryceh> benji, my wife is a Rockford Files fanatic
[23:11] <bryceh> we found out that netflix has the full run of Rockford in their online instant view thingee, so she can watch it whenever she wants.