[12:38] <bradb> ok, sanity check: is trying to login to the wiki telling other people "Sorry, wrong password" too?
[01:11] <carlos> jordi, pong
[01:11] <jordi> carlos: way too late
[01:11] <jordi> I'm shutting down, I wanted to import a few things, with you watching.
[01:11] <jordi> tomorrow
[01:11] <carlos> jordi, sorry, I just come back from my parents' house
[01:12] <carlos> ok
[01:12] <carlos> see you tomorrow
[04:50] <spiv> jamesh: Around?
[04:51] <jamesh> spiv: yeah
[04:52] <spiv> jamesh: The pending-reviews output for lifeless' arch-pqm branch seems weird to me.
[04:53] <spiv> There are conflicts that remove entire files.
[04:53] <jamesh> I just registered his robert.collins@c.c--general archive in my chinstrap home dir this morning
[04:54] <spiv> I just wanted a quick sanity check from you to know if it really does have crazy conflicts, or if you think something funny is going on.
[04:55] <jamesh> could be star-merge picking a bad ancestor
[04:56] <spiv> Well, pqm star-merges too.
[04:57] <jamesh> I'd ask lifeless, but he's on holiday
[04:57] <spiv> Right :)
[04:57] <bob2> hm, is there a reason bug activity isn't the default bug view?
[04:58] <jamesh> hmm
[04:58] <jamesh> http://people.ubuntu.com/~robertc/robert.collins@canonical.com--general/arch-pqm/arch-pqm--main/arch-pqm--main--0/patch-7/log shows the last item is a merge from rocektfuel
[04:59] <jamesh> s/item/revision/
[04:59] <spiv> Which means it shouldn't have crazy conflicts, I would have though.
[05:01] <spiv> patch-7?
[05:01] <spiv> I see a patch-52 from here.
[05:01] <jamesh> --general
[05:01] <jamesh> his public archive
[05:02] <spiv> Ah, right.
[05:02] <spiv> There's two branches there.
[05:02] <spiv> I got confused :)
[05:03] <spiv> Ok, I have another question...
[05:03] <spiv> Ah, you removed the other one because it was already merged?
[05:04] <jamesh> spiv: https://chinstrap.ubuntu.com/~jamesh/lifeless-pqm.patch <- without --star-merge
[05:04] <jamesh> yeah
[05:04] <spiv> So it was a dud merge.  Ta.
[05:05] <jamesh> the type of dud merge PQM will have trouble with too
[05:06] <spiv> Yep.
[05:07] <spiv> But that's something lifeless can sort out, I only need to mention it in passing in a review.
[05:07] <jamesh> I wonder if lifeless just did a full rocketfuel merge to his public archive, or a selective one?
[05:07] <jamesh> (which might account for weird merging)
[05:10] <jamesh> bob2: you mean the "activity log" malone page?
[05:55] <jamesh> spiv: w.r.t. Mark's branches, I think the comment on PendingReviews says it all: "I'm not sure - I want the diff magic to show me!."
[05:55] <jamesh> he's not after a review yet -- just wants the stats page to track the diff, conflicts, etc for him
[05:55] <jamesh> maybe it should have been tagged doesn't-need-review-yet or somehting :)
[06:00] <spiv> jamesh: Well, he should have put it in his own queue then ;)
[06:06] <spiv> In theory that could be fixed.
[06:06] <jamesh> I noticed that the names got fixed while the wiki was in Brazil
[06:07] <jamesh> but the changes since the moin 1.3 upgrade were broken
[06:07] <spiv> So long as everyone has the same wiki name in Launchpad as in the old wiki, it would be possible to write a script to migrate the old IDs to the new ones.
[06:07] <jamesh> now its switched back, so the data should all be there
[06:07] <spiv> The problem is that in Brazil, we were using plain moin 1.3.  We're now back on Launchpad auth, which uses different user ids under the covers.
[06:10] <jamesh> well, it is a problem that will become less important as time goes on
[06:10] <spiv> Yeah.
[06:12] <spiv> If we keep running local wikis for sprints, it'll be a recurring issue though.
[06:12] <jamesh> I think this was just a one off
[06:12] <jamesh> it's a pain for the people not at the sprint
[06:12] <elmo> no, we'll do local wikis as most meetings
[06:12] <elmo> well meetings where everyone is there
[06:13] <elmo> and it's easily avoided, since AFAIK we'll allowed to do the LP auth from anywhere, so next time I just need to give the data and the moin packages
[06:14] <jamesh> with the way the Launchpad sprint was structured, only somewhere between a third and a half the team were in Brazil at any one time though
[06:14] <spiv> Well, it wouldn't be hard to run a local authserver for a local wiki.
[06:14] <jamesh> if the wiki was moved to Brazil but still accessible, it wouldn't have been too bad
[06:15] <jamesh> even if it was slower
[06:16] <spiv> (It'd be a variation what we're planning for AuthserverCaching)
[08:21] <yaniv> Hello all! I had just noticed that Gaim is listed four times in the Hebrew Translation part of Rosseta, and at a glance, all version seemed identical. Does someone know anything about this? Is this a mistake, and we are doubling our work, or is it supposed to be like this?
[08:26] <jamesh> yaniv: what URL are you looking at?
[08:27] <yaniv> jamesh:https://launchpad.net/distros/ubuntu/breezy/+lang/he
[08:28] <jamesh> not sure.
[08:28] <yaniv> jamesh:if you search the page for gaim, you'll see it's list four times, (gaim-1, gaim-1 etc.) and the templates seem the same
[08:29] <jamesh> yeah.  if you click on the "source" column header they're all next to each other
[08:30] <jamesh> yaniv: the Rosetta guys should be waking up soon, so if you wait a bit you should get an answer
[08:30] <jamesh> they're on European time
[09:39] <sivang> jamesh: I have the bonobo helper lib ready, I will be sending it for your review soon
[09:40] <sivang> jamesh: I'm sure I have an handful of warths, make sure you let me know of them so I can fix *and* learn :)
[09:41] <sivang> jamesh: btw, must I use the autogen.sh script or make dist with it or can I drop it out of the tarball distribution?
[09:41] <jamesh> sivang: to get a tarball, you should run ./autogen.sh, then "make distcheck"
[09:43] <sivang> jamesh: ok, I'll do that shortly. up until now I just used "make dist" to move the tarball around between palces I worked in
[09:44] <jamesh> sivang: "make distcheck" makes a tarball, unpacks it and does a build, then tries to create a tarball from that copy
[09:44] <jamesh> it helps pick up bugs that'd bite you further down the track
[09:55] <sivang> jamesh: cool , thx for the info :)
[09:57] <sivang> jamesh: I alwasy do make clean and make dist clean before I reattempt building etc, is this ok?
[09:58] <jamesh> sivang: shouldn't be necessary
[09:58] <jamesh> sivang: "make distcheck" should give you a tarball suitable for building a package
[09:59] <sivang> jamesh: k, now, I get some autogen warnings. Should we continue this in a more appropriate channel (g-l, or g-h maybe? )
[10:00] <sivang> (feeling autotools stuff is getting bit OT for here)
[10:06] <SteveA> hi
[10:09] <jamesh> hi SteveA 
[10:10] <SteveA> hello jamesh
[10:11] <SteveA> i want to get the schemas that are used only for browser stuff moved into the launchpad/browser/ package somewhere
[10:12] <SteveA> this is kind of linked to making the autogenerated calendar forms have more user-oriented description fields
[10:12] <jamesh> just schemas, or all interfaces that are browser specific?
[10:12] <jamesh> okay
[10:13] <SteveA> because we can put schemas in there that extend the schoolbel schemas, but with improved descriptions (improved from the end-user point of view)
[10:13] <SteveA> that's a good question.  i don't know if we have any browser-specific interfaces that are not schemas
[10:13] <jamesh> I have some for calendar date ranges
[10:14] <jamesh> the implementations are in browser/cal.py
[10:15] <SteveA> date ranges sound very generic to me.
[10:15] <jamesh> okay
[10:15] <SteveA> more "structural", if you see what i mean
[10:15] <SteveA> so i guess we can keep them in launchpad/interfaces/
[10:15] <SteveA> what do you thin?
[10:15] <SteveA> think?
[10:16] <jamesh> it sounds like a good idea
[10:16] <jamesh> since the schemas used for data entry are likely to be similar to the interfaces for the real database objects
[10:16] <jamesh> and we probably don't want them mixed up
[10:17] <SteveA> mark originally wanted them to be kept together, because of the "keep all interfaces in one place" principle.  but, in brazil, he'd had sufficient experience of using them to come around to keeping them separate.
[10:17] <SteveA> this is what zope3 does, more or less
[10:18] <SteveA> so, we need to decide where to put them in browser code
[10:18] <SteveA> we can move them from interfaces/whatever.py to browser/whatever.py
[10:18] <SteveA> that way, there's no new modules being created
[10:19] <SteveA> and the schemas are in the same module as they are most likely to be used in
[10:19] <jamesh> so we won't do something like browser/interfaces.py?
[10:19] <SteveA> reducing the number of imports needed
[10:19] <SteveA> right
[10:19] <jamesh> okay.  that makes sense
[10:20] <jamesh> the "hard to find" aspect isn't as big a deal, for interfaces with only a single use
[10:20] <SteveA> in zope3, the standard is to put "external" interfaces in interfaces.py
[10:20] <SteveA> but "internal" interfaces near to where they are most often used
[10:21] <SteveA> everyone should be using ctags anyway
[10:21] <jamesh> so do we want to go through and move all browser level interfaces, or just keep it in mind during reviews?
[10:22] <SteveA> we should get them all moved into the right places.
[10:22] <SteveA> and also keep it in mind during reviews ;-)
[10:23] <jamesh> okay.  You mentioned extending the schoolbell interface for a data entry schema
[10:23] <jamesh> is that possible without redefining all the properties?
[10:23] <jamesh> (which is pretty much a new interface)
[10:24] <SteveA> it may be possible to say something like
[10:24] <SteveA>  class SchoolBellForBrowser(SchoolBellOriginal):
[10:24] <SteveA>      foo = SchoolBellOriginal.foo
[10:24] <SteveA>      foo.description = _("Better description")
[10:24] <SteveA> 
[10:25] <SteveA> i don't know for sure, though.
[10:25] <jamesh> that's going to update SchoolBellOriginal.foo.description though
[10:25] <SteveA> oh yeah
[10:25] <SteveA> i am still jetlagged ;-)
[10:25] <SteveA> so, you could do
[10:25] <SteveA>  foo = BetterDescription('foo', "Better description")
[10:25] <SteveA> where BetterDescription does:
[10:26] <SteveA>  - look up 'foo' from SchoolBellOriginal or its bases
[10:26] <SteveA>  - clones foo, provided it is a Field.  raises TypeError otherwise.
[10:26] <SteveA>  - resets the description on the clone
[10:27] <SteveA> BetterDescription would use the "class advice" hook
[10:27] <SteveA> so it actually runs after the SchoolBellForBrowser class suite is interpreted
[10:28] <SteveA> do you know about the class advice hook?
[10:28] <jamesh> no
[10:28] <SteveA> it is a fancy metaclasses trick
[10:29] <SteveA> i will get you some code, just a sec...
[10:29] <SteveA> launchpad/lib/zope/interface/advice.py
[10:29] <spiv> SteveA: Seems very magical.  Can't you just use foo = copy.copy(SchoolBellOriginal.foo); foo.description = _("Better description")?
[10:29] <SteveA> copy.copy sounds very magical to me ;-)
[10:30] <spiv> You do have a point there ;)
[10:30] <SteveA> but, if that works, it's great.
[10:30] <SteveA> i don't know if Fields support being copied.
[10:30] <SteveA> copying uses pickle
[10:30] <spiv> But I'd rate copy.copy as lesser evil than metaclasses ;)
[10:30] <SteveA> i think
[10:30] <SteveA> so if it does, it won't work
[10:31] <SteveA> the class advice hook is what 'implements(IWhatever)' uses
[10:31] <jamesh> spiv: do you think sqlobject should have a converter for set instances?
[10:31] <spiv> Well, it falls back to some of the same infrastructure as pickle, without actually pickling.
[10:32] <SteveA> jamesh: so you now have two approaches, either of which *might* work :-)
[10:32] <SteveA> see zope/interface/declarations.py for how advice is used, using addClassAdvisor
[10:33] <jamesh> that code is evil :)
[10:33] <SteveA> i'm only partly responsible :-)
[10:34] <spiv> jamesh: 
[10:34] <spiv> >>> class Ten(1,2,3,4):
[10:34] <spiv> ...     __metaclass__ = lambda n,b,d: sum(b)
[10:34] <spiv> ...
[10:34] <spiv> >>> print type(Ten), Ten
[10:34] <spiv> <type 'int'> 10
[10:35] <jamesh> I can see why it all works
[10:35] <spiv> (It such a shame Python doesn't let you say "class Ten(*range(5))"...)
[10:35] <SteveA> QUOTES PAGE!
[10:37] <SteveA> jamesh: can you move over the appropriate schemas to browser/ at the same time you improve the calendar schemas? 
[10:37] <jamesh> okay
[10:38] <SteveA> thanks
[10:38] <carlos> morning
[10:39] <SteveA> hi carlos
[11:09] <SteveA> carlos: what do you think about the message-id / original text in a comment thing that zope / plone uses?
[11:09] <SteveA> we'll be using this in a few places in launchpad too, i expect
[11:09] <SteveA> because of how page templates i18n works
[11:10] <carlos> SteveA, It should not be too difficult to implement a way to show it
[11:10] <carlos> in fact... I think it should work already
[11:10] <carlos> hmmm, no, perhaps no, as we only show comments that come from source code
[11:10] <carlos> but should be easy to extend Rosetta to show those other comments
[11:12] <SteveA> it would be a good thing to do soon, so the plone people can use rosetta well
[11:13] <carlos> the change to show those comments should be trivial, will try to do it later today
[11:15] <jstr> hey guys how long does it take for the verification email to be posted?
[11:16] <SteveA> jstr: do you mean for verifying that an email address is your own?
[11:17] <jstr> when you sign up for membership, and an email gets sent to address that you provide
[11:17] <SteveA> right
[11:17] <SteveA> it gets sent to you immediately
[11:18] <SteveA> any delay is from the normal short delay in sending email, or a longer delay if there's a routing problem to your mail server, or a *very* long delay if the address was mistyped
[11:19] <SteveA> we had a problem a few weeks ago where there was a misconfiguration in the launchpad internal mail systems, and mail wasn't getting out.  we fixed that, though.
[11:19] <jstr> its the right address... i think its just my slow crappy uni email address... oh well ill just wait it out
[11:40] <carlos> SteveA, btw, could you send me the emails about the pending reviews from daf?
[11:40] <carlos> SteveA, so I can finish the review changes and merge the branches?
[11:48] <SteveA> carlos: i don't know what you need
[11:48] <carlos> SteveA, you told me on Brazil that i should take care of the open reviews that daf has while he's offline
[11:49] <carlos> SteveA, so you told me that this week you woul try to send me the review emails sent to daf so I can merge those changes after the review changes are applied
[11:49] <carlos> do you remember it?
[11:52] <SteveA> i can't find any emails about these reviews
[11:52] <SteveA> so, i'm not sure where they will be
[11:52] <carlos> SteveA, ok
[11:53] <carlos> I will send an email to daf just in case he reads it before coming back to work 
[11:53] <SteveA> okay
[11:53] <SteveA> thanks
[11:55] <carlos> np
[11:57] <carlos> stub, I just requested a merge into rocketfuel for two fixes that should be cherry picked into production
[11:57] <carlos> stub, could you do it today?
[11:58] <carlos> one of the fixes needs also that you execute a script to migrate data
[12:14] <Kinnison> stub: can I ask you to cast an eye over daniel.silverstone@canonical.com--desktop/launchpad--rework-package-db--0 ?
[12:15] <Kinnison> stub: So far it's just all the database stuff for renaming BinaryPackage to BinaryPackageRelease and shuffling the publishing stuff around a touch more
[12:15] <Kinnison> stub: but it's quite a bit of db shuffling so I'd appreciate your eye on it
[12:22] <carlos> stub, btw, the error that you got with the whitespace migration script is a matter of move the .commit to another line and that should be all... I'm going to merge that fix too so we can finish that migration too
[01:08] <WaterSevenUb> hi... suppose I download "nano" po file from rosetta (breezy), and upgrade hoary to the latest nano breezy. Should the translation match the version of breezy?
[01:12] <jordi> WaterSevenUb: in theory yes
[01:12] <jordi> WaterSevenUb: it doesn't?
[01:14] <WaterSevenUb> jordi: well... some of the strings that are translated in the PO file, like in the "help" text of "nano", when I run the program appear in the original (english), not translated.
[01:15] <jordi> WaterSevenUb: any other very visible string?
[01:15] <jordi> WaterSevenUb: what language?
[01:15] <WaterSevenUb> jordi: ??, Portuguese
[01:16] <jordi> oh.
[01:16] <jordi> any other string that is translated but isn't showing up?
[01:19] <WaterSevenUb> jordi: there are a lot of strings that do not appear in the PO file... but from the translated ones that do not appear I'm only finding one... give me one minute.
[01:22] <WaterSevenUb> jordi: yes, there are... and what is more strange is that "Constantly show cursor position" in the PO file appears in "nano" as "Constant cursor position display"
[01:22] <WaterSevenUb> jordi: so it seems that I'm mixing versions...
[01:22] <jordi> WaterSevenUb: ok
[01:22] <jordi> what version of nano are you using? 1.3.8?
[01:22] <WaterSevenUb> jordi: yape...
[01:24] <jordi> WaterSevenUb: ok, from what I see, the translation in rosetta appears to be for 1.2.x (hoary)
[01:25] <jordi> I don't know why it's not tracking the breezy version yet.
[01:25] <jordi> Carlos?
[01:25] <WaterSevenUb> jordi: hmmm.. how do you see that?:)
[01:26] <jordi> WaterSevenUb: hmm, because I know the messages :)
[01:26] <carlos> jordi, https://launchpad.net/distros/ubuntu/breezy/+sources/nano/+pots/nano
[01:26] <carlos> jordi, that's breezy
[01:26] <jordi> I'm quite involved in nano upstream :)
[01:26] <jordi> carlos: why isn't it linked from https://launchpad.net/products/nano/+translations ?
[01:26] <WaterSevenUb> jordi: excellent! now I have someone to bother ;)
[01:26] <carlos> jordi, 1.3.7-2
[01:27] <carlos> jordi, because what I told you yesterday, you need to link the sourcepackage with a product series
[01:27] <carlos> so they appear there
[01:27] <jordi> carlos: and we need to do this for every product? sounds like fun.
[01:27] <carlos> jordi, right ;-)
[01:28] <carlos> but it only needs to be done once
[01:28] <jordi> carlos: so, https://launchpad.net/products/nano/+series/head/
[01:28] <jordi> do I "Link to Ubuntu package"?
[01:28] <carlos> future releases should reuse that information, you would only change the series if it's different
[01:29] <carlos> jordi, I think you were missing the needed permissions..
[01:29] <carlos> am I right?
[01:29] <jordi> totally right
[01:30] <WaterSevenUb> (hhmm... about a small note in Rosetta, in the top of each template translation, indicating the version that the template matches?)
[01:30] <jordi> is nano not in breezy?
[01:31] <jordi> WaterSevenUb: more than the version, what branch
[01:31] <carlos> jordi, it is
[01:31] <carlos> WaterSevenUb, well, it supposed to match latest version of that package in the distribution you are translating into
[01:32] <WaterSevenUb> carlos: :)
[01:33] <carlos> sorry, I killed my X server...
[01:35] <WaterSevenUb> jordi: can you send me a 1.3.8 PO file that I can work on while you try to sync things? Thanks.
[01:39] <carlos> WaterSevenUb, you can get it from the URL I pasted here
[01:40] <carlos> https://launchpad.net/distros/ubuntu/breezy/+sources/nano/+pots/nano
[01:41] <jordi> WaterSevenUb: There's a guy called Rui Azevedo or something who is working on pt (Portugal)
[01:41] <WaterSevenUb> carlos: thanks! I'm still not used to the many links in launchpad, sorry.
[01:41] <WaterSevenUb> jordi: I am that guy:-p
[01:41] <jordi> WaterSevenUb: me neither :)
[01:41] <jordi> WaterSevenUb: oh, great :)
[01:41] <jordi> WaterSevenUb: well, you've got mail :)
[01:41] <WaterSevenUb> jordi: :)
[01:42] <jordi> WaterSevenUb: translating official GNU projects is a bit annoying at the beginning
[01:42] <jordi> you'll read why
[02:00] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Fixed the fuzzy flag set/unset when importing a published .po file (r=SteveA). Changed @@absolute_url with fmt:url + pagetest added and fixed transaction problems with the whitespace migration script [trivial]  (patch-2242: carlos.perello@canonical.com)
[02:20] <carlos> SteveA, got the review emails from daf, I will try to merge those branches this week
[02:34] <jordi> carlos: I don't know why, but the breezy template of nano doesn't appear to be current.
[02:35] <carlos> jordi, the header says that it was generated on 2005-04-12
[02:35] <WaterSevenUb> carlos: "POT-Creation-Date: 2005-07-06 11:47:56.556271+00:00\n"
[02:35] <carlos> jordi, perhaps the problem is that the .pot file shiped with nano is not in sync with the code?
[02:35] <jordi> "POT-Creation-Date: 2005-06-30 13:24-0400\n"
[02:36] <jordi> this is from the tarball in Debian
[02:36] <WaterSevenUb> carlos: "POT-Creation-Date: 2005-07-06 11:47:56.556271+00:00\n" - this is from the header of the PO file I downloaded
[02:36] <carlos> jordi, is it the same we have in breezy?
[02:36] <carlos> WaterSevenUb, from Rosetta?
[02:36] <WaterSevenUb> carlos: yes.
[02:36] <carlos> then the problem is that the .pot file is outdated
[02:36] <jordi> that date matches the release date of nano 1.3.8
[02:37] <jordi> carlos: where, in rosetta or the tarball?
[02:37] <jordi> it is ok in the tarball
[02:38] <carlos> jordi, the imported version is 1.3.7-2
[02:38] <carlos> jordi, so perhaps that's the problem
[02:39] <jordi> yes, it is.
[02:39] <jordi> the strings WaterSevenUb is seeing untranslated chanegd between 1.3.7 and 13.8
[02:40] <carlos> jordi, seems like something is previnting our scripts to import the 1.3.8 version
[02:40] <carlos> WaterSevenUb, jordi would you file a bug report about it, please?
[02:40] <carlos> the tarball is there since 2005-07-22 so seems like there is a problem
[02:41] <jordi> do you have logs?
[02:41] <WaterSevenUb> jordi: I leave that to you :)
[02:41] <jordi> WaterSevenUb: yeah, don't worry.
[02:44] <carlos> jordi, yeah, but it's not easy to find that and I'm a bit busy to look at it atm
[02:44] <jordi> k
[02:45] <jordi> done
[02:48] <WaterSevenUb> jordi: #?
[02:49] <jordi> hmm. lost it
[02:49] <jordi> wait a sec
[02:49] <jordi> #   Bug #1729: nano 1.3.8 isn't imported in Rosetta
[02:49] <carlos> jordi, thanks
[02:51] <WaterSevenUb> thx
[03:06] <bradb> morning
[03:36] <SteveA> bradb: you know the wiki is back?
[03:37] <bradb> SteveA: yup, but login doesn't work for me ("Sorry, wrong password")
[03:37] <SteveA> bradb: use your launchpad password
[03:38] <bradb> that's what I've always done
[03:38] <bradb> do i have to use an lp email address now too?
[03:38] <SteveA> try it
[03:39] <bradb> oh, apparently i'm BradBollenbach2 now
[03:39] <bradb> (login with email worked, frighteningly enough)
[03:39] <SteveA> okay
[03:40] <SteveA> so, you need to ask stub to sort out BradBollenbach2
[03:47] <SteveA> bradb: you lost your subscribed pages, i think, with the upgrade to 1.3
[03:48] <bradb> bummer
[03:50] <bradb> was the upgrade botched?
[04:02] <SteveA> i have no idea
[04:04] <salgado> yo SteveA 
[04:05] <SteveA> hi salgado 
[04:06] <salgado> SteveA, I have the feeling that today you woke up with a special inclination for doing code reviews. (please tell me I'm right. ;)
[04:06] <SteveA> sure, i can do code reviews
[04:06] <SteveA> i'm off to the gym in a short while, though.  but, i can do reviews later today.
[04:07] <salgado> that's great. do you still have my mail about the smallfixes--4 branch?
[04:07] <SteveA> no idea
[04:08] <SteveA> i see that jamesh reviewed that a while ago
[04:10] <SteveA> after so long out of the normal flow of work, at the sprintathon, it's a good idea to send out fresh reminders of what you need from other people
[04:11] <salgado> I just bounced the mail. maybe you can give a quick look on the lines "@@ -325,13 +349,17 @@ class ValidateEmailView(object):" of the diff (https://chinstrap.ubuntu.com/~jamesh/pending-reviews/guilherme.salgado@canonical.com/launchpad--smallfixes--4/filtered-diff)
[04:11] <salgado> just to tell me how evil that hack is, and if I should remove it
[04:15] <SteveA> well, it looks okay to me
[04:15] <SteveA> i'd use the variable 'dupe_person_name' instead of 'dupe', and make it email.person.name
[04:15] <SteveA> because you are not using 'dupe' anywhere else
[04:17] <salgado> godd point
[04:17] <SteveA> a comment would help, explaining that the next section of code is going to detect a dupe
[04:17] <SteveA> and if so, return text that tells the user they can merge accounts
[04:17] <SteveA> the error message would ideally be given in the page template itself
[04:19] <salgado> IIRC that's not possible because that method has to handle too many corner cases. to have the messges in the template I'd need to check a lot of possible return values from the method
[04:20] <SteveA> well...
[04:20] <SteveA> you could have the method set self.is_dupe_email on the view instance
[04:21] <SteveA> or some other appropriate name
[04:21] <SteveA> and then simply check that in the template
[04:21] <SteveA> or, you can have more than one template for the view
[04:21] <SteveA> include them as ViewPageTemplate attributes
[04:21] <SteveA> and choose which one you want depending on what case you're dealing with
[04:22] <SteveA> there are various ways of doing it
[04:22] <SteveA> maybe the way you have chosen is already the simplest
[04:22] <SteveA> i can't say, without looking closely at all the code
[04:24] <salgado> I think the way I choose is simplest than these ones you proposed, but I think it'd be better if I set some attributes in the view class and then move the messages to the template itself
[04:26] <SteveA> english language: "is simpler"
[04:26] <SteveA> sure
[04:26] <SteveA> that sounds like a good plan, then
[04:27] <SteveA> it means that the text is in the page template
[04:34] <madduck> i have a burning question! was the name "Malone" chosen with any reference to Samuel Beckett?
[04:35] <Kinnison> Buggsy Malone (I imagine)
[04:39] <mpt> yes, with one g
[04:40] <mpt> http://images.google.com/images?q=bugsy%20malone
[05:07] <mpt> 99 conflicts of code in the files, 99 conflicts of code ... Take one down and merge it around, 98 conflicts of code ...
[05:09] <Nafallo> haha
[05:13] <madduck> ha
[05:13] <madduck> i am not acquainted with Bugsy
[05:13] <madduck> cute.
[05:13] <madduck> i read beckett over the weekend and it seems to be appropriate in places too. :)
[05:31] <kiko> ahoy
[05:33] <koke> hi!
[05:33] <koke> can you see https://launchpad.net/people/koke
[05:34] <koke> I've just merged two accounts and I can't see my personal page
[05:34] <kiko> salgado, another one :-(
[05:36] <carlos> kiko, !
[05:36] <carlos> koke, !
[05:36] <carlos> confusing, really confusing :-P
[05:36] <koke> :)
[05:37] <kiko> heh
[06:31] <jblack> keybuk: ping
[06:31] <Keybuk> jblack: yup?
[06:31] <jblack> Are you rather conversant on which debian guys work on which debian stuff? 
[06:32] <Keybuk> roughly
[06:32] <Keybuk> depends on the "stuff"
[06:32] <jblack> Cool. You know awesome things. :)
[06:32] <Keybuk> which things?
[06:33] <jblack> All of them that you could rattle off that could be potentially be usefully revision controlled
[06:34] <jblack> My goal is to chase down projects that need baz2 goodness, and help them across to it. 
[06:34] <jblack> Debian's internal stuff is a particularly sweet target, as they talk internally so much.
[06:36] <Keybuk> what kind of internal stuff?  dak and so-on?
[06:37] <jblack> Yeah. That and the install utils, anything that could be useful. I would target dpkg, but you're already sold I think. I've already sent an email off to apt. 
[06:38] <jblack> Basically, any deb project that could be revision controlled. If I get a handful of Deb guys selling it, then they'll sell the rest of debian over for me. (much like is happening with arch/gnome)
[06:38] <Keybuk> apt would be mdz ;)
[06:39] <Keybuk> dak would be elmo
[06:39] <Keybuk> installer stuff is joeyh, who may be a hard convert from svn
[06:39] <Keybuk> but Kamion and bubulle are big on that team too
[06:39] <mpt> koke: If you subscribe yourself to https://launchpad.net/malone/bugs/1314 you'll be notified when the bug is fixed
[06:40] <jblack> How about the install team? 
[06:40] <Keybuk> joeyh
[06:40] <mpt> koke: Actually, make that 131
[06:40] <mpt> 131
[06:40] <mpt> 333
[06:40] <mpt> gah
[06:40] <mpt> https://launchpad.net/malone/bugs/1313
[07:12] <mpt> Is there any way for a pagetest to say "this text does *not* occur anywhere"?
[07:14] <bradb-lunch> mpt: it's just python
[07:14] <bradb-lunch> so foo not in bar works
[07:15] <bradb-lunch> i don't know of a more readable way to do it
[07:15] <mpt> "it's just python" doesn't make something substantially easier for me :-)
[07:15] <mpt> What would be "bar" in this case?
[07:15] <bradb-lunch> >>> 'foo' not in 'bar'
[07:15] <bradb-lunch> True
[07:15] <bradb-lunch> >>> 'foo' not in 'barfoo'
[07:15] <bradb-lunch> False
[07:15] <bradb-lunch> so, foo is a variable with a string value in it
[07:15] <bradb-lunch> and so is bar
[07:16] <mpt> so foo = print http(r""" ... the rest of the test
[07:16] <bradb-lunch> no "print" there
[07:17] <mpt> oh, I see
[07:20] <mpt>   >>> 'HTTP/1.1 200 OK' in output
[07:20] <mpt>   True
[07:20] <mpt>   >>> 'Your subscription to this bounty has been updated' in output
[07:20] <mpt>   True
[07:20] <mpt>   >>> 'Foo Bar' in output
[07:20] <mpt>   False
[07:21] <bradb-lunch> actually not so terribly unreadable, i guess
[07:23] <bradb-lunch> the failure messages will be less informative, but then, they're already fully unreadable except by the most determined (and even then...)
[07:23] <mpt> heh
[07:23] <mpt> hmm, you have a point there
[07:24] <mpt> if the test fails I can't tell why
[07:25] <mpt> but that's true even if I test for anything in the usual ...way...
[07:25] <mpt> except for 500 errors, I guess
[07:30] <Kinnison> ciao
[07:35] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  add sampledata for sourcepackage bug list view class testing (patch-2243: brad.bollenbach@canonical.com)
[07:37] <kiko> i/o silver
[07:54] <carlos> see you
[07:55] <kiko> carlos!
[07:58] <carlos> kiko, !
[07:58] <carlos> kiko, I need to leave, do you need anything?
[08:03] <kiko> carlos, wanted to touch base, are you around later, or only tomorrow?
[08:03] <carlos> kiko, perhaps I will be around later, but I cannot give you a concrete time
[08:20] <bradb> SteveA: It seems as though we need a place to put classes that are "content classes" but are not tied to the database (e.g. BugTaskSearchParams is currently in the interfaces namespace :/) Would it be useful to create a canonical.launchpad.app namespace for this purpose?
[08:24] <kiko> bradb, note that SteveA was the one that suggested placing it in interfaces
[08:25] <bradb> evil! I created an interface for it and am now looking for a good home for the content class
[08:25] <kiko> bradb, note also that I have a patch here that moves createTask to IBugTarget as well, though I am not sure I like the general pattern so much here (I'm concerned we're straying from other launchpad patterns)
[08:25] <kiko> when SteveA is around I'd like a reping
[08:26] <bradb> sure (i have to leave in about 20 mins for a bit, but maybe he'll be back before then)
[08:27] <kiko> great
[08:48] <bradb> right, heading out for a bit, will read scrollback re: SteveA's/others thought on the .app namespace when i get back
[08:50] <kiko> ok
[10:19] <SteveA> bradb-bbl: BugTaskSearchParams should be in interfaces
[10:19] <SteveA> it is like an event
[10:19] <SteveA> or an exception
[10:20] <SteveA> it forms part of the contract between an IBugTarget and its user
[10:20] <SteveA> i don't expect to ever see more than one implementation of BugTaskSearchParams
[10:21] <stub> Goddammit it is still black outside
[10:24] <SteveA> cprov: noted about the meeting
[10:24] <SteveA> hi stu
[10:25] <cprov> SteveA: thank you man.
[10:25] <SteveA> bradb-bbl: don't create an interface for BugTaskSearchParams.
[10:25] <SteveA> it doesn't need an interface, the same as events and exceptions don't actually need interfaces
[10:25] <SteveA> it's just extra code to maintain
[10:29] <kiko-afk> heya stub 
[10:29] <kiko-afk> heya SteveA 
[10:29] <kiko-afk> do we have a meeting tomorrow?
[10:29] <SteveA> sure do
[10:29] <SteveA> it is in the channel title
[11:14] <bradb> no interface for BTSP...
[11:15] <bradb> SteveA: Should the interfaces package contain just interfaces, or should it contain things other than interfaces as well?
[11:15] <bradb> (like, say, BTSP_
[11:15] <bradb> )
[11:15] <SteveA> it already contains things other than interfaces
[11:15] <SteveA> it already contains things other than Interfaces
[11:15] <SteveA> basically, it should contain those things required to use "the interface" to the software
[11:16] <SteveA> these things include:
[11:16] <SteveA>  - Interfaces
[11:16] <SteveA>  - events
[11:16] <SteveA>  - exceptions
[11:16] <SteveA>  - objects that represent the parameters to methods
[11:17] <SteveA> so, really, the package should be called 'interface' or perhaps 'api' instead of 'interfaces'.
[11:17] <SteveA> but, zope3 has stuck with 'interfaces' as a convention.  we're broadly-speaking following what zope3 does.
[11:20] <bradb> SteveA: IOW, if a class is expected to only ever have one implementation, there should not be an Interface defined for it?
[11:21] <SteveA> that's one criteria, but it isn't sufficient
[11:21] <bradb> does the apidoc tool generate docs specifically for things that inherit from Interface?
[11:22] <SteveA> you can say: if a class is expected to only ever have one implementation, then you may consider not defining an interface for it.  There are, however, other good reasons to define interfaces for many things.
[11:23] <SteveA> in launchpad, we don't need to define interfaces for: interfaces (they already exist), events, exceptions, parameter objects.  Sometimes, the zope3 infrastructure makes things more convenient when we define an interface, for example for events or exceptions in some cases.
[11:23] <SteveA> but, this is arguably a shortcoming in zope3, rather than a best practice.
[11:24] <SteveA> apidoc understands interfaces (things that provide IInterface)
[11:24] <SteveA> and apidoc understands a lot of other things besides
[11:24] <SteveA> i must go to bed now -- trying to curtail the jetlag.
[11:24] <SteveA> before i go
[11:25] <SteveA> another way to look at the question of "where should BugTaskSearchParams go" is to consider what it is for
[11:25] <SteveA> it is part of the glue between browser code, or other application code, and database code
[11:25] <SteveA> you can think of the stuff in 'interfaces' as the glue
[11:25] <bradb> it's an object used to talk to the database code.
[11:25] <SteveA> right
[11:25] <SteveA> it isn't database code
[11:25] <bradb> not necessarily limited to browser -> db interaction
[11:26] <SteveA> nor is it application code as such
[11:26] <SteveA> it is glue
[11:26] <SteveA> that's why i said above "between browser code, or other application code"
[11:26] <bradb> right right
[11:27] <SteveA> dbschema stuff should really be in 'interfaces' too, but i'm not going to make that change just yet.
[11:27] <SteveA> for one thing, there are name collissions between dbschema classes and database classes
[11:27] <SteveA> for another thing, it is good to be able to clearly see what is a dbschema when it is used in code
[11:27] <bradb> it is indeed
[11:27] <SteveA> so, this needs some thought, and some new ideas
[11:28] <bradb> i wonder if BTSP belongs in searchbuilder then?
[11:28] <SteveA> i'll probably move it into canonical/launchpad/dbschema.py as a first step, though
[11:28] <bradb> or does the searchbuilder stuff belong in interfaces?
[11:28] <SteveA> it belongs with the interface that defines the operation it is used in
[11:28] <SteveA> that interface is IBugTarget, right?
[11:29] <bradb> or IBugTaskSet, i believe
[11:29] <bradb> yes, IBugTaskSet as well
[11:29] <SteveA> so, it belongs right next to IBugTarget or IBugTaskSet
[11:29] <SteveA> i see what you mean about searchbuilder, though
[11:29] <SteveA> where is that at the moment?
[11:30] <bradb> canonical/launchpad/searchbuilder.pt
[11:30] <bradb> .py, even
[11:30] <SteveA> so, i guess it could go there.  but, i seems a bit odd to me.  i wonder what others think.
[11:30] <bradb> I'd happily get rid of searchbuilder entireliy
[11:31] <bradb> NULL could simply be None
[11:31] <SteveA> well, one thing at a time
[11:31] <SteveA> i'm off to sleep.
[11:31] <SteveA> see you tomorrow -- launchpad meeting, btw
[11:31] <bradb> ok, i'll roll back the iface definition for BTSP, thanks. see you tomorrow morning.
[11:35] <bradb> kiko: so, there you go, i guess BugTaskSearchParams does belong in interfaces then because 1. it's part of the launchpad API and 2. we don't expect to have another implementation for it.
[11:36] <bradb> there might be other reasons as well, but those were the two that i gathered to be the most important from talking to SteveA 
[11:37] <kiko> yeah
[11:37] <kiko> bradb, do you think that doing IBugTarget.createTask is a good thing?
[11:37] <kiko> I have it done in my local tree but am still unsure
[11:38] <bradb> kiko: no, but i also don't think .searchTasks is particularly useful either. my thinking might be entirely wrong though.
[11:39] <bradb> kiko: do you think createTask is a good thing?
[11:40] <bradb> (or, put slightly differently, why are you unsure?)
[11:40] <kiko> well
[11:41] <kiko> searchTasks is useful if you want to do generic queries independent on what target it is
[11:43] <bradb> right, unless they evolve to have different params (like createTask)
[11:43] <bradb> at which point the value of IBugTarget's current API would seem to diminish
[11:44] <kiko> different params?
[11:44] <kiko> in what sense, bradb?
[11:44] <bradb> actually, they already do have different search params
[11:44] <kiko> really?
[11:44] <bradb> e.g. you wouldn't search for a specific sourcepackagename in an upstream
[11:44] <bradb> or bp name
[11:44] <kiko> good point
[11:45] <kiko> those are the only ones, right?
[11:45] <bradb> distrorelease
[11:45] <kiko> we could use params inheritance :-)
[11:46] <bradb> :P
[11:46] <bradb> productseries
[11:46] <bradb> productrelease
[11:46] <bradb> etc.
[11:47] <kiko> it's unfortunate -- I think the proper design would be to use a hierarchy of adapters (BaseTaskCollection and ProductTaskCollection, for instance) but it's not my call
[11:47] <kiko> and you'd adapt product to ITaskCollection
[11:48] <kiko> but that's subsets, isn't it?
[11:48] <bradb> i was just going to say...
[11:48] <bradb> :)
[11:48] <jblack> stevea: ping
[11:48] <bradb> i would agree that it's not as evil as it sounds though
[11:48] <jblack> nah. he's sleeping
[11:48] <kiko> it solves the problem better than a params instance
[11:49] <kiko> but let's let sleeping dogs lie
[11:49] <bradb> kiko knokws how to multi-task
[11:49] <bradb> :P
[11:49] <bradb> kiko: right
[11:49] <kiko> createTask() however does clean up some pretty gnarly if/elsing in one callsite
[11:49] <jblack> 17:44 < madduck> jblack: ok. lemme top off the night by telling you something
[11:49] <jblack>                  about me, and why i am even here...
[11:49] <jblack> 17:44 < madduck> i may well switch my phd field to workflow and productivity
[11:49] <jblack>                  management
[11:50] <jblack> 17:46 < madduck> so one of my first goals would be to improve the way teams
[11:50] <jblack>                  work on packages, and how to support multiple distros from a
[11:50] <jblack>                  single source
[11:50] <kiko> it appears that the pattern of the callsite not knowing what sort of target it has in its hand may not be that common
[11:50] <jblack> 17:46 < madduck> jblack: i'll be watching ubuntu, but i want to concentrate on
[11:50] <jblack>                  debian
[11:50] <jblack> (I didn't paste every line of his)
[11:50] <kiko> jblack, the best place for him to work is launchpad
[11:51] <bradb> kiko: interesting observation.
[11:51] <jblack> Basically, a guy is doing his phd on workflow analysis, wants to study the relationship between patchflow between distros.
[11:51] <kiko> observing relationships inside hct
[11:51] <kiko> (provided sourcerer is observing these distros)
[11:51] <jblack> He's talked to Mark at least once, has heard of hct. Seems like a good guy to tell more about.
[11:52] <kiko> yeah
[11:53] <Burgundavia> how do I assign a bug to someone now?
[11:53] <jblack> Imagine... launchpad being a thesis. 
[11:53] <bradb> Burgundavia: what screen are you looking at?
[11:54] <Burgundavia> https://launchpad.net/malone/bugs/1735
[11:54] <bradb> hey! what happened to the assign link!?
[11:54] <bradb> kiko: ^^ any idea?
[11:55] <kiko> Burgundavia, bradb: it's now edit/view a task.
[11:55] <bradb> i guess it was squished in favour of [edit] ?
[11:55] <kiko> yes
[11:56] <Burgundavia> oh there, ok
[11:56] <bradb> the 1.0 announcement will include a link to the FAQ, question #1 being "How do I assign a bug?" :)
[11:56] <bradb> which should reduce the number of times that question has to be answered by about 10%
[11:57] <Burgundavia> ok
[11:57] <Burgundavia> the edit link is a lot more sane than clicking the whole line
[11:57] <Burgundavia> I just didn't see it
[11:58] <bradb> that's our fault
[11:58] <bradb> but...that's likely how it'll work for 1.0 as well
[11:59] <kiko> we could add an icon as mpt has suggested in the past
[12:00] <bradb> given that the only clickable link in that row now (AFAIK) is the edit/view link, an icon could be a good way of drawing it out more
[12:00] <mpt> I could do that tomorrow
[12:01] <bradb> sounds good
[12:02] <dilys> Merge to rocketfuel@canonical.com/dists--devel--0: [trivial]  Update production-1.27 config (patch-104: stuart.bishop@canonical.com)
[12:02] <Burgundavia> it would be nice at the bug page to link to the main gnome-screensaver page with trranslations, bugs, etc.
[12:03] <mpt> That will happen automatically when