[12:01] <justdave> man, doing a star-merge with an empty revlib on a 233 MHz machine is a pain in the butt.
[12:02] <justdave> pulling from rocketfuel back to the desktop machine since the laptop is getting dismantled so I can return the dead hard drive in it.
[05:27] !dmwaters:*! Hi all, it looks as though one of our main rotation servers is having some network trouble.
[05:28] !dmwaters:*! This server was just pulled from rotation, and we're keeping an eye on it
[10:29] <elmo> does something in gnome set there polling the CD drive?
[10:29] <elmo> s/gnome/warty/ I guess since, I killed the X session
[11:25] <elmo> hmm, not having a root password, makes mistake like typo-ing 'usermod -s $SHELL user' that much more painful
[11:30] <carlos> elmo:  wrong channel?
[11:32] <carlos> spiv: ping
[11:39] <elmo> carlos: no? warty's the only system I know without a root password/user :p
[11:39] <carlos> elmo: but this is the #launchpad channel, not #ubuntu :-)
[11:40] <elmo> oh, so it is
[11:41] <carlos> :-P
[12:23] <lulu> daf: ping
[12:42] <SteveA> daf, carlos, lulu: can we have a rosetta meeting in 20 mins?
[12:43] <lulu> SteveA: yup - and Lalo and Limi?
[12:43] <carlos> SteveA: for me it's ok, but I think daf is not online now
[12:43] <SteveA> I had a chat with mark last night, and clarified some of the details of what we need to do with rosetta.
[12:55] <lulu> SteveA: I'd  recommend we have the full team present, as we now need to lay down what is/what is not deliverable for each milestone. It would be good for Limi and Lalo to be present. Thoughts?
[12:59] <SteveA> I think me, you, carlos and daf will be sufficient to discuss my conversation with mark last night
[12:59] <lulu> SteveA: ok
[01:20] <daf> hi everybody
[01:20] <daf> I'm just going to grab some breakfast -- be right back
[01:20] <lulu> hiya :o)
[01:22] <daf> ok, let's start!
[01:23] <carlos> daf: that was a fast breakfast :-P
[01:23] <daf> I'm still eating :)
[01:24] <carlos> :-)
[01:25] <lulu> Steve's just on a call with Jane...
[01:32] <lulu> daf: in the interim, could you check the rosetta server - it's down. cheers :o)
[01:37] <SteveA> hi, I'm back.
[01:38] <carlos> ok, could we start then?
[01:39] <carlos> I should go out in about one hour 
[01:39] <SteveA> yep, let's start
[01:40] <SteveA> I want to clarify our immediate goals for rosetta
[01:40] <SteveA> I had a talk on the phone with mark last night, and we talked in some detail about what rosetta needs to be able to do
[01:41] <SteveA> For our alpha, and beta releases, rosetta will be a "global rosetta"
[01:41] <SteveA> it will be available under rosetta.ubuntulinux.org
[01:41] <SteveA> there will be a hard-coded page there that lists the packages in ubuntu that we most want translation help on, with links into rosetta
[01:42] <SteveA> but, any packages/products will be available for translation in ubuntu's rosetta
[01:42] <SteveA> and if someone requests we add a product that isn't in ubuntu, that's fine, we can do so
[01:42] <SteveA> the products will still be availalbe, but won't be directly linked to the ubuntu rosetta front page
[01:43] <SteveA> we also want to put rosetta (same database, maybe even same app server) at rosetta.theshuttleworthfoundation.org or rosetta.tsf.org.za (or whatever it is)
[01:43] <SteveA> rosetta will be "marketed" first of all as a TSF project.  TSF is mark's non-profit organisation in south africa.
[01:44] <SteveA> TSF/mark will be approaching governments etc. in africa to get them interested in rosetta
[01:44] <SteveA> and in having a localized ubuntu
[01:45] <SteveA> this too will be a "global" rosetta, but with no "we want help with these ubuntu packages" page
[01:45] <SteveA> later on, after the beta, we'll want a rosetta.projectname.org, for example, rosetta.dia.org, for translating just the dia application.
[01:46] <SteveA> So, that's the context of the alpha / beta release.
[01:46] <SteveA> for functionality, we need two things:
[01:46] <SteveA> 1: A way for people to request new packages be added.  This can simply be a web form that emails daf, or emails the launchpad list.
[01:47] <SteveA> 2: someone is able to translate an application into a language of their choice, or add translations to a language an application is translated into already
[01:48] <SteveA> the overall functional test is "can I efficiently and effectively translate Dia into gaelic?"
[01:48] <SteveA> I'm done.  Does that make snese?
[01:48] <SteveA> or , sense, even
[01:50] <carlos> SteveA: the point 2) should be almost ready, the 1) is a new feature, but I don't think it's difficult to do it
[01:50] <limi> 1) is in there, but not wired up at the moment, I believe
[01:50] <limi> UI-wise :)
[01:50] <carlos> limi: perfect :-)
[01:51] <limi> of course needs HappyTalk Adjustment etc ;)
[01:52] <lulu> SteveA: so we have global Rosetta with the top projects on the home page, rathjer than
[01:52] <lulu> being dynamic, hard coded links to ubuntu packages
[01:53] <SteveA> right.  the ubuntu rosetta is a "global" rosetta, with a different homepage.
[01:53] <lulu> and the search will reveal all projects in "global Rosetta"
[01:53] <SteveA> we can make the software do this easily enough
[01:53] <SteveA> yes
[01:54] <lulu> that's fine - different to what Mark and I discussed yesterday.
[01:54] <SteveA> to make the software do this, we can have /rosetta and /ubunturosetta
[01:54] <lulu> how are we showing translation efforts then, as we have not got that sorted yet?
[01:54] <SteveA>  /rosetta can be an object that provides IRosettaApplication and /ubunturosetta an object that provides IUbuntuRosettaApplication.  We register a different homepage for the latter.
[01:54] <SteveA> we don't need translation efforts for the alpha or beta
[01:55] <limi> being sick is no fun :(
[01:55] <SteveA> leakfast or brunch
[01:56] <carlos> SteveA: translation efforts is not finished, in fact is frozen until "post-beta" phase
[01:56] <carlos> so we don't need to care about it
[01:56] <SteveA> good
[01:56] <daf> SteveA: the whole thing sounds fine
[01:58] <daf> and I believe translation efforts are not of concern at present
[01:59] <SteveA> daf: do you need to re-visit your document, given the above?
[02:01] <daf> yes
[02:02] <daf> I need to add the requirement for being able to request new projects
[02:02] <SteveA> can you do that now, and then we can talk about the revised doc a little later today
[02:02] <daf> sure
[02:04] <carlos> then, is the meeting over now?
[02:05] <SteveA> daf: great.  Shall we say in 1 hour?
[02:06] <SteveA> carlos: yes, thanks
[02:06] <carlos> ok, I will be back after lunch
[02:06] <carlos> cheers
[02:06] <lulu> SteveA: thanks for final definitive clarity.
[02:07] <SteveA> I had quite a long conversation about rosetta with mark last night
[02:07] <daf> SteveA: 1pm UTC?
[02:07] <SteveA> while he was walking around outside his parents' place, trying not to crush snails underfoot
[02:08] <SteveA> daf: yep, 2pm your time
[02:08] <SteveA> is that okay?
[02:10] <daf> yep
[02:10] <lulu> Limi needs to revise UI of the home page and place hard coded links on the page for all the Ubuntu applications. 
[02:10] <lulu> is the definitive list on the wiki for warty?
[02:10] <SteveA> I think we'll have the list of applications stored in python code
[02:10] <limi> indeed
[02:10] <SteveA> so, the ubuntulinux front page will get that list, and display it appropriately
[02:11] <lulu> so limi - you can get to the app list then?
[02:11] <limi> yup
[02:11] <limi> as long as there is a method that returns i
[02:11] <limi> t
[02:11] <lulu> great - can you do the ui for this page today?
[02:12] <limi> probably, dashboard is also a priority
[02:12] <SteveA> daf / carlos / lalo can do a mock-up that displays the data, and replace it with limi's golden version later
[02:12] <limi> my productivity is hard to predict, since I am not well yet
[02:13] <limi> sometimes I have to lie down in the middle of the day
[02:13] <limi> but today has been good so far
[02:13] <limi> so let's shoot for that ;)
[02:14] <lulu> great - so home page and dashboard is going for gold
[02:14] <limi> if not, a honorable silver ;)
[02:14] <limi> they should be functional, if not pretty
[02:14] <SteveA> we'll insist on doping tests for whichever gets gold
[02:14] <SteveA> so, you never know... silver may get upgraded
[02:15] <lulu> we are due to launch on the 15th September guys - 2 weeks away, so we need to start testing this final functionality that is now our goal.
[02:15] <lulu> limi: hope you feel better soon :o) - I know Vikings bounce back quickly!
[03:04] <SteveA> daf: how's the revision going?
[03:04] <daf> I've revised the document
[03:08] <daf> NotFoundError: (<RosettaProject at 0xb41dd74c>, 'title')
[03:08] <daf> eh??
[03:10] <SteveA> I'm reading through the document now.
[03:11] <lulu> At the conference, we agreed that the task board was very useful to keep track of daily tasks.
[03:11] <lulu> and that we should have a meeting every day to track progress
[03:11] <lulu> is the team in agreement that we should continue this?
[03:12] <daf> I foudn it very effective while we were physically together
[03:12] <SteveA> daf: when we have this page that mails you to request a new project be included, how will you actually include the new project?
[03:13] <SteveA> daf: what are the bugs in po import?
[03:14] <SteveA> #
[03:14] <SteveA> Submitting new/updated translations.
[03:14] <SteveA>     *
[03:14] <SteveA>       Partially implemented, being worked on by Daf.
[03:14] <SteveA> do we have a list of things needed before this is fully implemented?
[03:14] <daf> I can't work on this because too many other things are broken
[03:14] <daf> traversals are broken
[03:14] <SteveA> let's take one thing at a time.
[03:14] <daf> adapting principals to persons is broken
[03:15] <SteveA> first, bugs in po import
[03:15] <SteveA> do you have a list of these bugs?
[03:15] <daf> the PO import causes duplicate message IDs in PO files
[03:15] <daf> that's the only one I can think of
[03:15] <daf> we don't have a list
[03:16] <SteveA> ok, please file that bug in bugzilla
[03:16] <daf> which Bugzilla?
[03:16] <SteveA> https://bugzilla.warthogs.hbd.com/bugzilla/
[03:17] <SteveA> there's a rosetta product/component in there
[03:17] <SteveA> who is going to fix that bug?
[03:18] <daf> Lalo is
[03:18] <SteveA> is he working on it now?
[03:19] <daf> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=1905
[03:19] <daf> I have no idea
[03:20] <SteveA> please mail lalo, and give him that bug URL, and ask him to work on fixing that bug
[03:20] <daf> he'll have already gotten mail when I assigned that bug to him
[03:21] <SteveA> better to mail him, and actually ask him to work on it
[03:22] <daf> I'll add a comment to the bug
[03:22] <daf> which he'll get by email
[03:23] <daf> done
[03:23] <SteveA> ok
[03:24] <SteveA> what are the bugzilla logins?
[03:24] <SteveA> I have my password, but I don't know what login id to use/
[03:24] <daf> they are email addresses
[03:24] <SteveA> I tried that
[03:24] <SteveA> I guess I need a new password...
[03:26] <SteveA> we need to note in the bug that we must have a unit test or a functional test for this
[03:26] <SteveA> also, a description of how to reproduce the bug would be good, so we know how to empirically test that the bug is fixed.
[03:27] <SteveA> this could be in the form of a doctest in the bug report.
[03:27] <SteveA> oh, I must show you the new zope3 functional doctests soon -- now with no need for set-up boilerplate!
[03:28] <daf> ooh
[03:28] <SteveA> we need to get lalo to estimate the task of fixing this bug
[03:28] <daf> getting lalo would be a start...
[03:28] <SteveA> is it 1/2 day, 1 day, ...?
[03:28] <daf> no idea
[03:28] <daf> I don't know the import code well enough
[03:29] <daf> I don't have a test case
[03:29] <SteveA> lalo should estimate it, not you
[03:29] <daf> I just noticed it happening as I was fixing the ftests
[03:29] <SteveA> please add to the bug's notes that task 1 is to write a test case
[03:29] <daf> oh, rhetorical question
[03:29] <SteveA> task 2 is to fix it
[03:31] <daf> ok, another comment added
[03:31] <SteveA> great
[03:32] <SteveA> next, let's talk about submitting new / updated translations
[03:32] <daf> feel free to CC yourself to this bug
[03:32] <daf> ok
[03:32] <limi> 1) Create translation tool
[03:32] <SteveA> we need to come up with the list of things that stand in the way of your doing this
[03:33] <daf> first of all, I need to be able to see the translation template
[03:33] <daf> limi: I think this step is the hard one
[03:33] <limi> yes, me too
[03:33] <daf> this is prevented by at least two things
[03:33] <daf> first, traversing to this template doesn't work
[03:34] <daf> second, adapting IPrincipal to IPerson doesn't work
[03:34] <SteveA> traversing to which template doesn't work?
[03:34] <SteveA> please give a URL table spec
[03:34] <daf> https://rosetta.warthogs.hbd.com/++skin++Debug/rosetta/projects/gnome/evolution
[03:34] <daf> any templates beyond project are affeted by this
[03:35] <daf> I've been working on a fix for this
[03:35] <daf> I'm confused by this "rosettaProducts" method
[03:35] <SteveA> maybe you'd like me to work on fixing this?
[03:35] <SteveA> I probably caused the bug
[03:36] <SteveA> stick a bug in bugzilla, and assign it to me
[03:36] <daf> I think you did
[03:36] <daf> but I also think I've fixed it
[03:36] <daf> by adding IRosettProject.produt
[03:36] <SteveA> what is the fix?
[03:36] <daf> .product
[03:37] <SteveA> I don't think that's the right way to fix it.
[03:37] <SteveA> Here's what I suggest:
[03:37] <SteveA> * keep your fix in your sandbox, so you can keep working
[03:37] <SteveA> * assign the bug to me in bugzilla, and I'll work on it
[03:38] <daf> sandbox?
[03:38] <SteveA> * add the patch you used to fix it to the bug in bugzilla
[03:38] <SteveA> by "sandbox" I mean your own tree on your laptop
[03:38] <SteveA> which may contain uncommitted code
[03:39] <daf> it doesn't
[03:39] <SteveA> it doesn't what
[03:39] <SteveA> ?
[03:39] <daf> contain code which hasn't been merged to rocketfuel
[03:40] <SteveA> so, you have already merged your fix?
[03:40] <daf> no
[03:40] <SteveA> the notion of "sandbox" is just, "place where you do work"
[03:40] <SteveA> you are playing in your own sandbox
[03:40] <daf> yes
[03:41] <SteveA> ok.  does that address that problem of traversal?
[03:41] <SteveA> you can keep working, I'll fix it in RF
[03:42] <daf> but it will cause more work for me later, won't it?
[03:42] <SteveA> what will cause more work for you?
[03:42] <SteveA> (got to lose that pronoun habit!)
[03:42] <SteveA> ;-)
[03:42] <daf> resolving our differing fixes
[03:42] <daf> pronoun habit? :)
[03:43] <daf> oh, "it"?
[03:43] <SteveA> I had to ask what "it" was
[03:43] <daf> sorry
[03:43] <SteveA> you'll be able to just remove your fix
[03:43] <SteveA> once mine is in RF
[03:43] <daf> ok, we'll do it this way
[03:43] <SteveA> ok
[03:43] <SteveA> next, principal --> person
[03:44] <daf> https://rosetta.warthogs.hbd.com/++skin++Debug/rosetta/translator
[03:44] <daf> (as exhibited by)
[03:44] <SteveA> ok, here's the problem:
[03:45] <SteveA> we have principals who are people who have logged in
[03:45] <SteveA> we have the unauthenticated principal, which is the state of the system when no-one has logged in
[03:46] <SteveA> when you want to present something that depends on the Person who is logged in, you need to check that a person actually is logged in
[03:46] <SteveA> we can do that in two ways
[03:46] <SteveA> 1: set a permission on the page so that a person must be logged in to access it
[03:46] <daf> how do we do that?
[03:46] <SteveA> 2: check to see if a person is logged in, and present something else if not
[03:46] <SteveA> easiest way to do "2" is:
[03:46] <SteveA>   person = IPerson(request.principal, None)
[03:47] <SteveA>   if person is None:
[03:47] <SteveA>       # nobody is logged in
[03:47] <SteveA>   else:
[03:47] <SteveA>       # use person.languages or whatever
[03:47] <daf> at the moment, I think (2) is appropriate for the pages we have
[03:47] <SteveA> we probably want to change request/lp:person to return None if nobody is logged in
[03:47] <SteveA> I don't know if it does that or not
[03:48] <SteveA> So, let's add a bug!  in fact, let's add two
[03:48] <SteveA> 1: check all uses of IPerson(request.principal) to see if they do something sensible when no-one is logged in
[03:48] <SteveA> 2: check the implementation of request/lp:person to make sure it works right
[03:49] <SteveA> I think there was some evil hard-coding of your name in the IPerson adapter code too :-)
[03:49] <SteveA> so, perhaps we have 
[03:49] <SteveA> 3: check that the IPerson adapter code is as it should be
[03:49] <daf> the implementation returns None on the unathenticated princiapl
[03:49] <SteveA> you can assign bugs 2 and 3 to me
[03:49] <daf> I don't think Zope likes that
[03:49] <SteveA> bug 1, I think you should do
[03:50] <SteveA> you may be right.  I'd like to look at it closely.
[03:50] <SteveA> add the bugs, and I'll go through the ones assigned to me.
[03:50] <daf> ok
[03:52] <daf> steve@z3u.com is your Bugzilla ID?
[03:52] <SteveA> yes
[03:52] <SteveA> justdave: we should look at changing these to canonical addresses
[03:52] <SteveA> or allowing both/either
[03:53] <SteveA> daf: so, with IPerson(request.principal, None), you should be able to proceed.
[03:53] <SteveA> What else is blocking you?
[03:53] <daf> the strange database error I was getting
[03:54] <SteveA> bbiam. biobreak.
[03:55] <daf> the software is willing, but the hardware is weak?
[03:55] <daf> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=1906
[03:56] <justdave> SteveA: yeah, changing all to canonical.com addresses makes sense now that we have them.
[03:57] <SteveA> justdave: perhaps suggest it on the warthogs list, then assuming no complaints, do it?
[03:57] <SteveA> also, is it possible/easy to have a drop-down of people I can assign bugs to?
[03:58] <SteveA> or get bugzilla to know about mail aliases, so I can just enter fabbione@canonical.com rather than fabbio.massimo.di.nitto@canonical.com as an assignee
[03:59] <daf> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=1907
[03:59] <justdave> SteveA: yeah, that was just added recently...  I need to upgrade it anyway to get the fixed search stuff (the "find a specific bug" search is partially broken at the moment)
[04:00] <justdave> I'll turn on the drop-down boxes once I get it upgraded
[04:00] <SteveA> justdave: when will you be doing the upgrade?
[04:01] <justdave> depends on how involved it winds up being to do it and keep our local hacks.  I'll try it on a local copy here tonight, and if it goes off well, the ones on macquarie can probably get upgraded tonight or tomorrow.
[04:01] <justdave> downtime is usually less than a minute if I have it prepared ahead of time, so most folks won't even notice, but I'll still post a time so people know to stay clear.
[04:02] <SteveA> elmo: was there some talk about bugzilla moving from maquarie to somewhere else, so that bugzilla is running on a different machine to the app servers?
[04:02] <daf> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=1908
[04:02] <daf> ok, done
[04:02] <SteveA> daf: great
[04:03] <SteveA> database problems?
[04:03] <daf> es
[04:03] <daf> yes
[04:03] <daf> I can't recall the details now
[04:03] <SteveA> not sure I have much to go on
[04:03] <daf> I pasted it to the channel
[04:04] <SteveA> do you keep logs?
[04:04] <elmo> stevea: yes.  when we have the new servers
[04:04] <SteveA> or we can get fabbionne's logs
[04:04] <SteveA> elmo: when will that be?
[04:04] <daf> 17:52 <daf> DatabaseException: unindexable object
[04:05] <SteveA> elmo: (just approximately... out of interest)
[04:05] <SteveA> daf: can you work out some instructions for reproducing that error?
[04:06] <SteveA> that'll be the kind of thing that is easiest to investigate from the post-mortem debugger
[04:06] <daf> once I can reproduce the error again, yes
[04:07] <SteveA> if you can't reproduce it, then it is actually holding you up?
[04:09] <spiv> carlos: pong
[04:10] <spiv> daf: hat's probably a % quoting issue.
[04:10] <daf> I could last reproduce it before I did a star-=merge which introduced these new bugs
[04:10] <spiv> Try using %% instead.
[04:11] <SteveA> hi andrew
[04:11] <spiv> (cursor.execute does a '....' % params internally)
[04:11] <spiv> SteveA: Good moprning.
[04:11] <daf> spiv: hmm, could be
[04:11] <daf> spiv: this was in a selectBy, IIRC
[04:11] <spiv> daf: I got confused by that yesterday, which is why I know ;)
[04:11] <SteveA> are % quoting issues listed on the SQLObject page on the wiki?
[04:12] <SteveA> if not, someone who understands the issue should add a note there
[04:12] <spiv> daf: Hmm, it might still trigger there (although if it did, it would be a bug in SQLObject)
[04:12] <spiv> SteveA: Not yet, but good diea.
[04:12] <spiv> idea, rather.
[04:12] <daf> spiv: is this something that would be easy to check?
[04:13] <SteveA> spiv: will you update the docs?
[04:13] <spiv> daf: If I'm understanding your question, try putting '%' in a search form, and see what happens.
[04:14] <spiv> SteveA: Yep
[04:14] <SteveA> thanks
[04:14] <daf> spiv: not a search form
[04:15] <elmo> stevea: I don't know, I'm still in reseller hell, trying to get sabdfl friendly prices
[04:15] <SteveA> oh, hp
[04:15] <elmo> (and dell and ibm)
[04:15] <SteveA> we should just become a reseller... and ship ubuntu pre-installed ;-)
[04:16] <daf> spiv: I did enocunter this problem when I implemented our search
[04:16] <daf> spiv: and found, through experiment, that using %% fixed it
[04:16] <daf> this was a couple of weeks ago
[04:16] <daf> this might be a similar problem
[04:17] <SteveA> daf: when you find out something like that, do send an email to the list
[04:17] <SteveA> then, we can all learn from that, and perhaps someone who knows the internals can comment on the best way to do it
[04:17] <daf> SteveA: I thought it was an SQL weirdness rather than a Python weirdness
[04:17] <daf> but yes, I shuold have emailed the list
[04:18] <daf> spiv: I can't reproduce it right now, but I should be able to later
[04:18] <daf> spiv: how's New York?
[04:18] <daf> spiv: or have you already left?
[04:18] <spiv> daf: This is a psycopg wierdness, I think.  Certainly not an SQL weirdness.
[04:18] <spiv> daf: Here for one more night.
[04:18] <SteveA> daf: I need to have another meeting about now.  Did we go through all the things blocking you?
[04:18] <spiv> It's big and dirty :)
[04:19] <daf> spiv: please give my regards to Mika
[04:19] <daf> SteveA: I think so
[04:19] <spiv> Ok.
[04:19] <daf> SteveA: I need to go and have lunch anyhow
[04:19] <daf> is Mako back there yet?
[04:19] <SteveA> daf: ok.  Let's talk again in 2 or 3 hours
[04:20] <daf> SteveA: let's
[04:21] <daf> spiv: dirtier than London? :)
[04:21] <spiv> daf: Not yet.  He's apparently bouncing around DC and Seattle atm.
[04:21] <daf> ah, right
[04:22] <spiv> daf: Looks like it to me -- a dozen garbage bags at every street corner kind of dirty... but then, I didn't really see any of London apart from South Kensington. :)
[04:23] <daf> well, London is mostly dirty through smog, I think
[04:23] <daf> limi: what do you think?
[04:24] <limi> yes, I think London is dirty ;)
[04:25] <daf> dirty in what way?
[04:25] <limi> carpetness, toilets, general hygiene
[04:25] <limi> the city itself isn't that bad
[04:25] <limi> it's the people ;)
[04:26] <daf> heh
[04:26] <limi> hehe
[04:26] <daf> I mostly notice the air quality when I go there
[04:26] <daf> limi: I thought it was 7 million? :)
[04:27] <daf> it also has chewing-gum-encrusted-pavement syndrome, but that's common to lots of Britain
[04:35] <lalo> Porto Alegre is wet too
[04:37] <lalo> hello all
[04:38] <lalo> daf: yt?
[04:38] <SteveA> hi lalo
[04:38] <SteveA> daf has just gone to have lunch
[04:38] <lalo> oh, ok
[04:39] <SteveA> you have a bug assigned to you
[04:39] <lalo> I can try to unearth this bug while he's eating
[04:39] <SteveA> also, you might want to read the irc logs of the meeting earlier, or alternatively / additionally, look at the https://www.warthogs.hbd.com/RosettaAlpha page
[04:40] <lalo> ok
[04:43] <lulu> hi lalo - good to see you :o)
[04:44] <lalo> hey lu
[04:44] <SteveA> lalo: so, the first thing with that bug is to estimate it
[04:45] <SteveA> then, test case (and maybe re-estimate after that)
[04:46] <lalo> SteveA: the first thing, I believe, is finding it - I can't estimate if I don't know what will be involved in fixing
[04:47] <SteveA> in that case, it is good to say "I'll spend X hours looking into it, then do an estimate"
[04:47] <SteveA> this makes the work more visible to others
[04:48] <lalo> ok
[04:48] <SteveA> if you haven't got to a good point after X hours, then we (you, me, daf) need to talk about it
[04:48] <SteveA> we might need a different approach / look for the problem in a different place
[04:49] <lalo> that's 1h, I suppose.
[04:50] <lalo> but not immediatly - I'll start after I'm done with the logs
[04:51] <SteveA> logs?
[04:51] <SteveA> oh, right
[04:51] <SteveA> actually, read the wiki page,
[04:51] <SteveA> and I'll email you the relevant portion of the logs
[04:52] <lalo> already did the wiki page
[04:52] <lalo> and the logs are not too big
[04:52] <spiv> daf: mika says hi :)
[04:53] <SteveA> ok
[05:03] <carlos> wow, a really big log since I went to have lunch. I'm in sync now
[05:03] <carlos> SteveA: I saw the comment about the check for logged and non logged people, is the +login page working now?
[05:04] <SteveA> sorry, not yet.
[05:05] <carlos> spiv: I fixed the problem I had already, but it's interesting to know how could I work with tables that does not have an "id" field (to do Object.select(...) and Object.selectBy(...))
[05:05] <carlos> SteveA: hmm, then if it's not logged, I will hardcode a person. Ok? 
[05:06] <SteveA> carlos: can you do it as a query string?
[05:07] <SteveA>   page?personid=123
[05:07] <spiv> carlos: SQLobject requires an "id" field.
[05:07] <SteveA> that's a temporary way to move forward
[05:08] <spiv> (it allows you to call it something else if you really want, and has ver ylimited support for non-integer id fields, but the existence of a unique id for a row is fundamental to how it works)
[05:08] <carlos> SteveA: will it be done in the future that way?
[05:08] <SteveA> no
[05:09] <carlos> spiv: Then, look at TranslationEffortPOTemplate table
[05:09] <carlos> spiv: I'm not able to work with it (is not important now, so we don't need to find a solution for "now")
[05:11] <spiv> carlos: Ok, that table needs to be fixed then.
[05:11] <spiv> I think there's a handful of others.
[05:11] <carlos> I "fixed" the problem with the table PersonLabel using RelatedJoin's add and delete methods, in fact it's the correct way to do it, but with the that other table, we have an extra field I need to be able to fetch
[05:12] <carlos> SteveA: then? I think it's easier if I detect that the person is not logged to just forge Daf's user until you have your code in place
[05:12] <SteveA> ok, whichever works best for you
[05:13] <daf> SteveA: any idea what could be causing this error?
[05:13] <daf> NotFoundError: (<RosettaProject at 0xb41ef5ec>, 'title')
[05:13] <SteveA> from that, no
[05:13] <SteveA> I need to pop out for a short while.
[05:13] <SteveA> mail me if you want me to look into something
[05:14] <daf> it's an error from a simple TAL expression in the translation template
[05:15] <daf> SteveA: ok
[05:22] <carlos> daf: As I saw, we are using then bugzilla as our bts?
[05:39] <daf> yes
[05:40] <carlos> ok
[05:53] <lalo> daf: hello world
[05:55] <carlos> lalo: you are alive! :-P
[05:56] <lalo> daf: glad to see we have separate interfaces now. However I do believe either:
[05:56] <lalo> a. that one method needs to be in the "broader" messageset interface, as it applies to anything you might want to import
[05:56] <lalo> b. OR, I could special-case pot-sets in the import adapter, if you think that's cleaner
[06:00] <carlos> daf: I'm going to fix the login problem, if it's someone logged in, we use that info, if it's an anonymous, I will use your user preferences
[06:01] <carlos> daf: as soon as SteveA finish it, we could just remove the hardcoded person and redirect to the login page or show anonymous data
[06:01] <carlos> daf: is that ok for you?
[06:02] <carlos> hmmm
[06:02] <carlos> there is already some code to do it so seems like we only need the hardcoded value to be able to test rosetta
[06:08] <lalo> augh. I won't be able to reproduce this bug today :-/
[06:12] <lalo> well, I suppose I can find it even if I don't reproduce it
[06:32] <daf> lalo: hmm, it happened for me when I ran the import ftests repeatedly
[06:33] <daf> lalo: I don't object to having methods both for PO sets and POT sets
[06:33] <daf> lalo: but I can't see how this method applies to POT sets
[06:33] <lalo> well
[06:33] <lalo> I'm not sure :-)
[06:34] <lalo> if I try to think whether it does conceptually apply, I get mixed feelings
[06:34] <lalo> but I think it's a choice of having an ugly special case in the method OR an ugly special case in the caller code
[06:34] <lalo> in this case I think moving the special case to the caller code is the better choice
[06:35] <daf> I agree
[06:37] <lalo> do you have 30m to help me find my bug? I still can't run postgres on this machine (bought RAM, but had a technical problem with it, so it will only be in production tomorrow)
[06:38] <daf> hmm, that sucks
[06:39] <lalo> if you can help, great - if not, I ask leave to fix that bug tomorrow
[06:39] <lalo> (assuming we can find other things for me to do today)
[06:40] <lalo> I have a pretty good feeling about where the bug originates from... seems to be an odd interaction with your refactorings
[06:41] <SteveA> lalo: could you debug on the "rosetta" machine if you had an account there?
[06:42] <lalo> SteveA: yes
[06:42] <lalo> is the database in that machine breakable?
[06:43] <daf> if we give you access to it, yes :)
[06:44] <lalo> def breakable(self): return not self.important()
[06:45] <daf> I know what you meant :)
[06:45] <daf> yes, it's ok if it's broken
[06:51] <SteveA> we can ask the admins to give lalo an account
[06:51] <SteveA> then he can run a rosetta in his account on the same port the devel server uses, and temporarily stop using the devel server
[06:51] <SteveA> alternatively, lalo could experiment on the devel server
[06:53] <daf> or we could make Apache mirror more ports, so we can have multiple servers running simultaneously
[06:53] <daf> s/mirror/proxy/
[06:53] <SteveA> this is just for this week, say until monday
[06:53] <SteveA> let's keep the changes to a minimum
[06:53] <lalo> have to figure out if it's worth it - if it takes more than a few hours I'd better wait for my new mobo and work locally
[06:54] <SteveA> we can simply ask the admins to give lalo an account for 1 week.  then you can change permissions to allow lalo to diddle with the devel server.
[06:54] <SteveA> daf: it's up to you to choose what you think will work best.
[07:00] <daf> let's give lalo an account on rosetta, modify the permissions on the development server, and give him database access
[07:00] <SteveA> daf: mail admins@admins, and ping elmo
[07:01] <SteveA> oh, I just did ping elmo
[07:05] <daf> email sent
[07:06] <lalo> daf: since we're currently using the same class for both, what should I do if the method is called on a pot-set? raise?
[07:07] <daf> +        if self.poFile is None:
[07:07] <daf> +            raise RuntimeError(
[07:07] <daf> +                "This method cannot be used with PO template message sets!")
[07:07] <daf> is what I'vebeen doing
[07:08] <lalo> ok
[07:08] <lalo> also: since we now have a separate interface, shouldn't we probably add a method that returns the corresponding pot-set?  and if yes, what should it be called?  maybe self.templateMessageSet()?
[07:11] <daf> if that would be useful, yes
[07:11] <lalo> ok, will do
[07:11] <daf> it might be useful to have a POTemplateMessageSet.copyToPOFile(language)
[07:12] <daf> can you think of any disadvantages to having two separate tables?
[07:12] <lalo>         if self.poFile is not None:
[07:12] <lalo>             raise RuntimeError, """This method cannot be used with PO template
[07:12] <lalo>                 message sets!"""
[07:12] <lalo> broken :-P I'll fix
[07:13] <daf> if not, we should move to two mesage set tables after the alpha has begun
[07:13] <daf> (I don't want to cause too much disruption now)
[07:13] <lalo> despite the different methods? well, it would be an useful optimization if the po-set stored a reference to the pot-set; and if this was done, I suppose some fields can be eliminated (primemsgid maybe)
[07:13] <daf> despite? because of!
[07:13] <lalo> sorry
[07:14] <lalo> s/despite/apart from/ :-P
[07:14] <daf> and it's not really an optimisation thing, it's a design thing
[07:14] <lalo> I think (not sure) I meant "besides"
[07:14] <carlos> lalo: primemsgid is also used to prevent duplicated msgid, I don't think we should remove it
[07:14] <daf> we wouldn't have to have these checks in the code
[07:14] <lalo> I'm not sure which is worse, disruption now or after the alpha
[07:14] <carlos> I don't think we should do it for the alpha
[07:14] <daf> I think primemsgid is a useful optimisation
[07:14] <lalo> I mean removing primemsgid from the po-set table
[07:15] <lalo> it doesn't need that information - it will be unique on (pot-set, language)
[07:15] <carlos> hmmm, right
[07:15] <daf> does every PO file message set have a template message set?
[07:15] <carlos> I thought you was thinking on nuke it completely
[07:16] <lalo> daf: not currently, but if we split the tables, I think it would be good to enforce that
[07:16] <daf> does that cope with obsolete messages?
[07:16] <carlos> daf: not always, but I thought that the split will move the msgid to potemplates and the msgstr to the pofile one
[07:17] <carlos> daf: not really, we could add them to the potemplate
[07:18] <lalo> currently if you import a fresh pot&po (meaning, the database never had a previous version of these), then the obsolete po-sets will have no corresponding pot-sets
[07:18] <daf> right
[07:18] <carlos> I thought that the idea behind the split is that the msgid will be only with potemplates and msgstr with pofiles...
[07:18] <lalo> but if we had separate tables, then I'd vote on creating a pot-set automagically for it, with sequence=0
[07:18] <daf> the idea behind the split is this: we have two different kinds of message sets: ones from templates, and ones from PO files
[07:19] <daf> they have different attributes and methods
[07:19] <daf> given this, it's silly to squeeze them both into one table/class
[07:19] <daf> I wasn't thinking any further than that
[07:20] <daf> we would clone the existing table definition, and delte the attributes that don't apply
[07:20] <carlos> ok, then we should only duplicate the tables and add an extra field that points the pofile ones to the potemplate ones
[07:20] <carlos> and that's all
[07:20] <lalo> if you asked me as a consultant, I'd say: think carefully, and if you're going to split, split before the alpha. After that it will be too disruptive.
[07:20] <daf> e.g. POTemplateMsgSet wouldnot have a pofile attribute
[07:20] <daf> nor a fuzzy attribute
[07:21] <daf> nor an obsolete atribute
[07:21] <daf> etc.
[07:21] <daf> I would prefer to make this change after tha alpha
[07:21] <daf> rationale:
[07:21] <lalo> specially since, after the beta, you'll already have data in the database, and would therefore have to come up with a script to migrate it if you split the tables
[07:21] <daf> we want to implement the functionality necessary for the alpha as quickly as possible
[07:22] <daf> once this is done, we can do some cleaning up
[07:22] <daf> this change would be a cleaning-up change
[07:22] <daf> data from the alpha is not precious
[07:22] <carlos> daf: that's ok for me, and also, I think we should do it after the alpha. We should finish the alpha as soon as possible we have only 15 days to finish the alpha + beta process and start in production mode, we cannot delay the alpha
[07:22] <daf> so it doesn't matter too much if we break things
[07:23] <carlos> lalo: we will only migrate the user accounts information, nothing more
[07:23] <lalo> I think you misunderstand me
[07:23] <lalo> after the alpha goes live, we'll have real message sets in the db
[07:23] <carlos> lalo: but will be deleted when we move to beta
[07:23] <daf> yes
[07:23] <lalo> sorry
[07:24] <daf> but we won't keep them
[07:24] <daf> and the testers will know this
[07:24] <lalo> if you're proposing to make this change between alpha and beta, then you're crazy :-)
[07:24] <daf> any translations they make they want to keep, they will have to export as PO
[07:24] <lalo> if you don't make it before the alpha, you have to make it *during* the alpha
[07:24] <daf> doing it before the alpha will delay things too much
[07:25] <carlos> lalo: that's the point, we put the alpha in place and then, we do the needed changes and at the same time the betatesters are playing already with rosetta
[07:25] <lalo> yup
[07:26] <daf> no, we want to finish this change before the beta starts
[07:26] <carlos> lalo: different database
[07:26] <lalo> but then we need to put the new status quo live for testing *during* the alpha, not when we switch to beta
[07:26] <carlos> daf: ok, alphatesters :-P
[07:26] <lalo> and therefore we have to migrate the existing message sets
[07:26] <daf> no
[07:26] <daf> just delte everything and start again
[07:29] <daf> database changes aside, how much code would we need to change?
[07:29] <lalo> difficult question
[07:30] <lalo> would you like me to make a formal estimate?
[07:30] <daf> anything that refers to a message set, I suppose
[07:30] <lalo> (sounds like a perfectly reasonable use of my time while I wait for investigating the bug)
[07:30] <daf> yes, an estimate would be useful
[07:30] <lalo> not necessarily EVERYthing - I suppose a good portion of the code will still just work
[07:31] <daf> well, anything which refers to it by name will need to change
[07:31] <lalo> my poor importer will suffer :-P but it will be for the better
[07:31] <daf> for great justice! :)
[07:31] <lalo> yes, but BRM makes that point-and-clicky
[07:31] <carlos> daf: I think the database modifications are still lost, that means that we will not store new data from rosetta and that means that we have a serious problem....
[07:31] <carlos> modifications from rosetta
[07:32] <daf> lost?
[07:32] <daf> you mean not committed to the database?
[07:32] <carlos> daf: they are never committed
[07:32] <carlos> yes
[07:32] <daf> I haven't merged my changes which do that yet
[07:32] <carlos> daf: you have a fix?
[07:32] <daf> because they still have some bugs
[07:32] <daf> well, it's not implemented in the rocketfuel version at all
[07:33] <carlos> I'm not talking about translations
[07:33] <daf> oh
[07:33] <carlos> daf: I just executed some methods to remove rows
[07:33] <carlos> and they are not anymore on the user interface
[07:33] <carlos> but the database still have them 
[07:33] <daf> hrmph
[07:38] <carlos> daf: exactly, the delete is there but the commit is never done
[07:38] <carlos> spiv: ?
[07:40] <spiv> carlos: Hmm.
[07:40] <spiv> You've turned on the SQLObject debugging?
[07:41] <carlos> spiv: I don't think so, how could I do it?
[07:41] <carlos> I have activated the postgresql log for the statements
[07:41] <carlos> that's why I know the delete was executed, but was not committed
[07:42] <daf> carlos: your copies of sqlobject and sqlos are up-to-date?
[07:42] <carlos> daf: yes, I updated them about 1 hour ago, when I remember that Stuart did some fixes
[07:42] <carlos> but the problem is still there
[07:43] <carlos> Now, rosetta shows always the correct values, but as soon as it's stopped, the changes are lost
[07:43] <spiv> carlos: The easiest way is to edit sqlobject/dbconnection.py atm, line 28.
[07:44] <spiv> Some day we'll turn that into a config option somehow.
[07:44] <carlos> ok
[07:44] <carlos> where could I see the debug info?
[07:45] <spiv> It'll print it to stderr, iirc.
[07:45] <carlos> yes, it does it
[07:45] <carlos> daf: I know why the language query is so slow...
[07:45] <carlos> getUtility(ILanguages)
[07:46] <carlos> expands to more than 600 selects
[07:46] <carlos> one for every row Language table has
[07:46] <daf> ouch
[07:46] <daf> I think we can make that faster
[07:47] <daf> oh, hmm
[07:47] <daf> ok, I can't see why it's doing that
[07:48] <daf> spiv: any idea?
[07:49] <spiv> daf: Are you building 600 seperate RosettaLanguage objects?
[07:49] <carlos> I iterate over all languages, but I suppose it should not be the problem...
[07:49] <carlos> spiv: yes
[07:49] <carlos> is that the problem?
[07:49] <daf> spiv: not just by instantiating RosettaLanguaages, no
[07:50] <carlos> daf: I iterate over all languages 
[07:50] <spiv> daf: RosettaLanguages.keys()
[07:50] <carlos> to create a list
[07:50] <daf> carlos: ah
[07:50] <daf> that's why, then
[07:50] <carlos> but that's crazy!!
[07:50] <spiv> Really, SQLObject ought to be smart enough to do that in one query.
[07:50] <spiv> But I don't think it is yet.
[07:50] <daf> perhaps we should have ILanguages.__list__()
[07:50] <daf> so we can do
[07:51] <daf> for language in list(languages):
[07:51] <spiv> daf: eh, __list__ isn't a python magic method
[07:51] <spiv> You're perhaps thinking of __iter__.
[07:51] <daf> erm
[07:51] <spiv> Or maybe keys ;)
[07:51] <daf> :)
[07:51] <daf> I think I was thinking of __iter__ :)
[07:53] <carlos> look, I'm using it this way:
[07:53] <carlos> for code in allLanguages.keys():
[07:53] <carlos>             if allLanguages[code]  in interestedLanguages:
[07:53] <carlos>                 selected = True
[07:53] <carlos>             else:
[07:53] <carlos>                 selected = False
[07:53] <carlos> and allLanguages = getUtility(ILanguages)
[07:54] <carlos> interestedLanguages is a python list of Languages
[07:54] <spiv> Ah, it's the lazyColumns attribute that's the problem, maybe...
[07:54] <spiv> Hmm, no, that defaults to False.
[07:55] <carlos> spiv: the SQLObjects only show lots of QueryOne and some QueryAll but nothing more
[07:56] <carlos> (about the database modifications problem)
[07:56] <spiv> carlos: No COMMITs or ROLLBACKs?
[07:56] <carlos> no
[07:56] <daf> carlos: how about this:
[07:56] <spiv> Hmm.
[07:56] <daf> for code in [ x.code for x in interestedLanguages ] :
[07:57] <daf>     foo(allLanguages[code] )
[07:57] <daf> hmm, frob was probably a better metasyntactic variable than from there
[07:57] <carlos> daf: I need to list all languages
[07:57] <daf> oh, I see
[07:59] <daf> for now, I think the best thing would be to add ILanugages.__iter__
[07:59] <daf> for language in allLanguages:
[07:59] <daf>     if language in interestedLanguages:
[07:59] <daf>         # ...
[08:00] <spiv> daf: Well, SQLObject is supposed to fetch everything at once when approriate.
[08:00] <daf> spiv: I think "supposed to" is the important part here :)
[08:00] <carlos> X-)
[08:01] <spiv> daf: Well, I'll spend a few more minutes looking at the code, to see if I can figure out why it's not :)
[08:01] <daf> spiv: thanks :)
[08:02] <carlos> but please, give more priority to the problem updating DB data, we cannot start the alpha phase without that 
[08:03] <spiv> carlos: Good point.
[08:04] <spiv> I've got an up-to-date rocketfuel checkout; how do I reproduce this?
[08:04] <spiv> (I'm not very familiar with rosetta)
[08:04] <carlos> spiv: the easier way:
[08:05] <carlos> make launchpad_test at launchpad/database/schema
[08:05] <carlos> make run
[08:05] <spiv> Got that too ;)
[08:05] <carlos> visit http://localhost:8085/++skin++Debug/rosetta/translator
[08:05] <carlos> the skin++Debug could be removed
[08:05] <carlos> and after some seconds you will get a list of languages
[08:06] <carlos> deselect one (for instance, Welsh) and submit it
[08:06] <carlos> the PeopleLabel table should be updated
[08:06] <carlos> but it's not 
[08:07] <carlos> spiv: but wait, you will need some of my local changes
[08:07] <carlos> I will commit them  now
[08:07] <carlos> spiv: and don't select a new language, only deselect it, the addition feature is not working and you will get an error :-)
[08:08] <spiv> Ok, thanks.
[08:08] <carlos> merge request sent
[08:15] <SteveA> looking in sqlos/transaction/__init__.py, I don't see the fixes stu and I made in there
[08:16] <SteveA> ok, I just updated, and they're there
[08:16] <SteveA> carlos: do you have an up-to-date sqlos ?
[08:16] <carlos> yes
[08:16] <SteveA>     def prepare(self, txn):
[08:16] <SteveA>         if self.prepared:
[08:16] <SteveA>             raise TypeError('Already prepared')
[08:16] <SteveA>         self.prepared = True
[08:16] <SteveA>         self._checkTransaction(txn)
[08:16] <SteveA>         self.transaction = txn
[08:16] <SteveA>         self.state += self.delta
[08:16] <SteveA>         if self.objects:
[08:16] <SteveA>             for obj in self.objects:
[08:16] <SteveA>                 obj.sync()
[08:17] <SteveA>         return True
[08:17] <carlos> same code here
[08:17] <SteveA> ok
[08:18] <carlos> spiv: my code is now at rocketfuel
[08:18] <spiv> carlos: Yes, I saw, grabbing now..
[08:19] <spiv> Whee, lots of options :)
[08:20] <carlos> spiv: go to the end of the page
[08:20] <carlos> spiv: limi will "fix" it
[08:21] <spiv> Ok, I see the bug.
[08:21] <spiv> Now I need to obey workrave for 10 minutes :)
[08:21] <spiv> Then I'll dig deeper.
[08:21] <carlos> :-P
[08:21] <carlos> ok
[08:21] <SteveA> the blinky red oblong of doom
[08:23] <lalo> woot, freshmeat is borked :-P
[08:25] <carlos> lalo: works here
[08:25] <lalo> I get "Error connecting to MySQL Server."
[08:26] <carlos> I'm behind a transparent proxy, perhaps that's the "problem"
[08:27] <lalo> yeah, you may be getting a cached copy
[08:27] <lalo> daf: my refactoring just reached rocketfuel, when you have a few minutes please check if it's sufficient
[08:28] <lalo> argh
[08:28] <lalo> no it didn't :-P I forgot to add the auto-mirror hook to my arch setup
[08:28] <lalo> brb
[08:29] <carlos> lalo: #!/bin/sh
[08:29] <carlos> if [ "$1" == "commit" ] ; then
[08:29] <carlos>         tla push-mirror $ARCH_ARCHIVE $ARCH_CATEGORY
[08:29] <carlos> fi
[08:29] <lalo> thanks
[08:29] <carlos> .arch-params/hook
[08:29] <daf> no, that's buggy
[08:29] <carlos> $HOME/.arch-params/hook
[08:29] <daf> there is no ARCH_REVISION
[08:29] <daf> #!/bin/sh
[08:29] <daf> if test "$1" = "commit"; then
[08:29] <daf>         ARCH_CATEGORY=`tla parse-package-name -c $ARCH_REVISION`
[08:29] <daf>         tla archive-mirror $ARCH_ARCHIVE $ARCH_CATEGORY
[08:29] <daf> fi
[08:29] <carlos> daf: that's what I have since our meeting at London...
[08:30] <daf> you probably copied it from me before I fixed mine :)
[08:30] <carlos> but it works...
[08:30] <daf> er, sorry
[08:30] <lalo> having experimented with working both ways, I think I prefer not to have the hook
[08:30] <daf> carlos: sure, but it won't limit the mirroring properly
[08:30] <carlos> ok
[08:30] <daf> since ARCH_CATEGORY will be ""
[08:31] <lalo> an average once a week I want to "undo" a commit, and auto-mirror makes that painful.  I prefer mirroring in the script that submits to pqm.
[08:31] <lalo> (which right now I don't have either :-( but I can fix that after work hours)
[08:32] <daf> lalo: bad commits don't matter, because they're not merged to rocketfuel automatically
[08:32] <daf> I often make mistakes, but it doesn't matter because I susually catch them before they go to rocketfuel
[08:32] <lalo> yup
[08:33] <carlos> daf: ok, hook fixed. I suppose that if it fails (network problems) I will need to execute the push by hand
[08:33] <lalo> the problem lies not in rocketfuel, but in the way I prefer to deal with those mistakes :-)
[08:33] <daf> mirroring when you merge is probably more efficient, though
[08:33] <lalo> if I'm not mirrored I can just delete the revision; if I'm mirrored, deleting a revision becomes dangerous
[08:34] <daf> call the arch police!
[08:34] <daf> lalo is deleting revisiosn!
[08:35] <carlos> X-)
[08:37] <lalo> :-)
[08:57] <lalo> ok, *now* it's merged
[09:00] <carlos> hmmm
[09:00] <carlos> is possible to get a segmentation fault with python??
[09:00] <carlos> wow
[09:01] <spiv> carlos: It's not supposed to be, but there are buggy extension modules...
[09:01] <carlos> I think it should be psycopg
[09:01] <carlos> Is the only change I did to that script
[09:02] <lalo> import massdestruction; massdestruction.segfault()
[09:02] <lalo> oh, freshmeat is working again. "The other rosetta" seems to be abandoned...
[09:03] <carlos> lalo: yes, it is
[09:06] <SteveA> I had a chat with mark about login names and traversing people's names
[09:06] <SteveA> any objections to using email addresses as login ids?
[09:07] <lalo> is it the plan that I can login using any of my verified addresses?
[09:07] <SteveA> yes
[09:07] <lalo> and - with the same password?
[09:08] <SteveA> yes
[09:08] <carlos> SteveA: it's ok for me
[09:08] <lalo> sounds ok. Can I request that an address is verified *without* logging in?
[09:08] <SteveA> out of scope for this conversation
[09:09] <lalo> well, as an user, I'd be ok with using the email as a login, IF that condition is true
[09:09] <SteveA> here's mark's suggestion of how to do traversing people's names
[09:09] <SteveA> there should be a person's nickname in the context of a particular project
[09:10] <SteveA> so, jeff could be jdub in the context of gnome, but I could be the ubuntu jdub
[09:10] <SteveA> as a silly example
[09:10] <cprov> SteveA: do you mean: http://people.ubuntu.com/markshuttleworth@hbd.com ?
[09:10] <daf> lalo: did you finish that estimate?
[09:10] <SteveA> this avoids the political problems of trying to be the one unified namespace of nicknames
[09:10] <debonzi> SteveA, why not a unique username for login and traversing?
[09:11] <lalo> daf: no, I'm working on it - just started a few minutes ago, as I understood (perhaps wrongly) that you wanted that refactoring first
[09:11] <daf> lalo: I wanted the refactoring first
[09:11] <daf> :)
[09:11] <SteveA> debonzi: that will put us in the position of making a single namespace for people's names in the world of open source
[09:12] <SteveA> that's an awkward position to be in
[09:12] <lalo> another thing that's out of scope now but I'd really like to stay on record: future phases of Rosetta *need* that one email address is "preferred" for a person; it's ok if it's "preferred" in the context of a project or product. We need this to insert email addresses in exported headers.
[09:12] <kiko> SteveA, not really. sf.net does the same.
[09:12] <SteveA> lalo: file a bug
[09:12] <lalo> ok
[09:12] <SteveA> sf.net sucks :)
[09:13] <SteveA> and, I always forget my login to sf.net
[09:13] <SteveA> I don't forget my email addresses
[09:13] <cprov> SteveA: huh
[09:13] <kiko> that's beyond the point -- the idea is a possible one.
[09:13] <kiko> and much less prone to complexity than using email addresses.
[09:14] <cprov> SteveA: let's setup the technical details, again: http://people.ubuntu.com/markshuttleworth@hbd.com, should it work for us ?
[09:15] <kiko> I really think using emails is going to make things complex.
[09:15] <kiko> I see no problem with people.ubuntu.com/kiko 
[09:15] <kiko> and first-come-first-served.
[09:16] <SteveA> there are two separate issues here
[09:16] <SteveA> 1. login ids
[09:16] <SteveA> 2. traversing names in the system
[09:16] <kiko> if you forget your sf.net address, hey, you can always ask to be reminded of it.
[09:16] <kiko> SteveA, yes, but merging them is a really good idea.
[09:17] <lalo> yes. I find login-by-email awkward, but bugzilla and passport have proven it viable
[09:17] <carlos> kiko: how?, if you don't know you login name...
[09:17] <kiko> carlos, enter your email address and ask to be reminded.
[09:17] <kiko> lalo, ask justdave about the problems with having email as login.
[09:18] <lalo> I don't need to - I don't like it :-P
[09:18] <carlos> I prefer it, look at drupal or jabber :-)
[09:18] <lalo> but I think it's viable - if that's what is decided, I can live with it. That's what I'm saying.
[09:18] <kiko> oh, we can live with anything!
[09:18] <lalo> carlos: jabber does *not* log in by email
[09:18] <kiko> that's not the point here. we're looking for a *good* solution
[09:19] <carlos> lalo: log in with an email like token
[09:19] <lalo> carlos: not really
[09:19] <lalo> carlos: you log in with an username, which is unique in the context of the server you're logging in to
[09:19] <carlos> kiko: I gave you examples of good solutions :-)
[09:19] <SteveA> the issue of login id is not important right now
[09:19] <SteveA> it will not hold up anyone's work
[09:19] <SteveA> let's talk about traversing people
[09:20] <cprov> SteveA: that is my point ...
[09:20] <SteveA> thanks celso
[09:20] -dmwaters(dmwaters@dmwaters-gentoo.staff.freenode)- {global notice} Hi all! Freenode is in the process of building a new ircd to replace the current dancer1.0. This needs to be done soon, and the code does need to be clean. If anyone is interested on helping code on this project, please stop by #newircd and talk to us. Have a nice day, and thank you for using freenode!
[09:21] <SteveA> so, mark's suggestion would be that http://people.ubuntu.com/mark (or something like it) should work
[09:21] <kiko> okay.
[09:21] <kiko> is that all?
[09:21] <debonzi> SteveA, and it is not a unique username?
[09:21] <SteveA> but, http://people.ubuntu.com/mark may be a different mark than http://soyuz.fedora.org/people/mark
[09:21] <kiko> hmmmm
[09:21] <cprov> SteveA: xii
[09:22] <kiko> distro-specific usernames?
[09:22] <SteveA> project-specific
[09:22] <cprov> SteveA: mark == givenname ?
[09:22] <SteveA> xii ?
[09:22] <SteveA> mark == nickname
[09:22] <kiko> distro-specific, SteveA -- from your example.
[09:22] <kiko> ubuntu and fedora would be different namespaces.
[09:22] <SteveA> is fedora not a project?
[09:23] <kiko> it's a distribution; I have no idea what a project is in the soyuz context. we don't use it.
[09:23] <SteveA> http://soyuz.gnome.org/people/mark
[09:23] <kiko> huh?
[09:23] <kiko> soyuz.gnome.org?!
[09:23] <SteveA> that's why I didn't give it as an example
[09:23] <spiv> SteveA: This is the first I've heard of a soyuz.$project.name.domainname
[09:23] <kiko> thanks spiv.
[09:23] <spiv> s/\.name//
[09:23] <SteveA> but, rosetta.gnome.org/people/mark
[09:23] <kiko> I have *never* been told anything about soyuz.gnome.org.
[09:23] <SteveA> it was an example to illustrate the pattern
[09:23] <SteveA> forget the "soyuz" part
[09:24] <SteveA> and read "canonicalapp." instead
[09:24] <kiko> the only thing we agreed upon was soyuz.${distro.name}...
[09:24] <kiko> hmmm.
[09:24] <SteveA> this issue is not just for soyuz
[09:24] <spiv> kiko: Actually, soyuz.${distro.domainname} (just a nitpick :)
[09:24] <kiko> right :)
[09:24] <kiko> I'm right now at a loss as to what should be done here and now then.
[09:25] <SteveA> to get things going for the soyuz sprint, I suggest using person int ids
[09:25] <kiko> is soyuz/people different from rosetta/people or are we going to have a global people?
[09:25] <SteveA> and we'll discuss these issues at the sprint
[09:25] <SteveA> we have global people
[09:25] <kiko> okay.
[09:25] <cprov> I fell mayself totally lost on it
[09:25] <SteveA> let me put it another way:
[09:26] <SteveA> * we have global people
[09:26] <spiv> SteveA: Well, more generally, this is the first I've heard of canonicalapp.${project.domainname} :)
[09:26] <kiko> spiv, same here.
[09:26] <SteveA> * we want nice nicknames for people when traversing urls for them
[09:26] <SteveA> * we don't want a global namespace of nicknames.  people are called different things in different contexts.
[09:26] <SteveA> * for soyuz, a context is a distro
[09:27] <SteveA> * let's not change anything in the database just now
[09:27] <SteveA> spiv: you've heard of rosetta.gnome.org, surely?
[09:27] <spiv> SteveA: I might have.  I can certainly imagine it more easily than soyuz.gnome.org :)
[09:27] <kiko> I'm having a hard time believing we won't have a global namespace of nicknames.
[09:28] <kiko> if these tools are going to have the integration we want them to have I am going to be really mad
[09:28] <kiko> if I'm called creis in malone and kiko in soyuz and christian.reis in rosetta.
[09:28] <kiko> it's like kicking the user in the nuts <wink>
[09:28] <SteveA> we like kicking users in the nuts :-)
[09:29] <SteveA> it is limi's job to stop us short
[09:29] <spiv> SteveA: Anyway, I'm a little torn here.  What you're proposing certainly would work, but the inherent complexity of having multiple aliases for the same thing makes me nervous.
[09:29] <SteveA> indeed
[09:29] <kiko> my proposal is
[09:29] <kiko> - front a global namespace
[09:29] <SteveA> so, that's why we do nothing but think about it now
[09:29] <kiko> - have a global people/ thing
[09:29] <limi|nearby> nice little system you have here - too bad if something should... happen to it.
[09:29] <kiko> - use the nicks as logins and as traversal strings
[09:30] <kiko> - have people sent their login data via email if they forget it
[09:30] <kiko> - enjoy life while it lasts
[09:30] <kiko> everything here is superlative, I can't believe we're worried about being a global namespace when freshmeat, slashdot *and* sf.net do it.
[09:31] <spiv> Although, we're resigned to having multiple names for things already -- even with the same nick, we'd have soyuz.ubuntu.org/..../spiv and rosetta.gnome.org/..../spiv  (whatever .... might be).
[09:31] <cprov> I agree with kiko in this point, why can't we use a plain unique login name ?
[09:32] <kiko> spiv, that's a lot better than soyuz.ubuntu.org/.../spiv showing your bug console as malone.ubuntu.org/.../andrewb 
[09:32] <kiko> and it's going to keep both developers and users sane.
[09:32] <SteveA> until the soyuz sprint, logins are emails, and the soyuz team can make the best of what we have for traversing people.
[09:32] <spiv> kiko: If you ask Mark, I'm sure he'd say we're planning on being bigger than freshmeat, slashdot and sf.net combined ;)
[09:32] <SteveA> we can't sanely change until then
[09:33] <kiko> spiv, I know, though that doesn't necessarily mean a unique login is a bad thing (nor that it will be easy beating slashdot's # of registered users -- considering what type of site /. is and what launchpad is).
[09:34] <cprov> ok, we have an end point, traverse by email ...accepted !
[09:34] <spiv> SteveA: I'm certainly ok with logins as emails as a starting point.  It's not hard to move to allowing nicks as well later, if that's what we decide.
[09:34] <kiko> cprov, he said traverse by whatever you feel is acceptable.
[09:34] <kiko> as long as you don't change the DB
[09:35] <SteveA> make it "work" now.  make it "really good" at the sprint.
[09:35] <cprov> kiko: I traverse the ID in the current release ... so, it's done 
[09:36] <kiko> aham.
[09:36] <SteveA> cprov: maybe file a bug in bugzilla to say that traversing by person id is a "bug" just now, and we'll work out how we want to do it at the soyuz sprint ?
[09:37] <cprov> SteveA: I will do so 
[09:38] <SteveA> thanks
[09:59] <kiko> SteveA, there's an interesting paper in ACM Interactions (May/June2004) that talks about competitions in open environments, it might be interesting to harness this for triages and bugfixes and other things that can be done competitively and collaboratively.
[10:01] <kiko> I read it yesterday evening
[10:02] <SteveA> cool
[10:02] <SteveA> post a summary to warthogs@ perhaps?  or a link if it is availalbe?
[10:03] <kiko> maybe a summary if I find some time, I'm pretty sure a link is only available to ACM dl members.
[10:05] <SteveA> or just the existence?  I think others on the team will be ACM members, especially USians
[10:07] <kiko> okay. will do that then.
[10:21] <spiv> carlos: Still tracking down the uncommitted delete transaction bug, but I've found out more about the performance while I was there ;)
[10:22] <spiv> carlos: Turns out that the RosettaLanguages.keys() is doing the right thing, and issuing the one query -- it's the repeated calls to __getitem__ after that causes all the little selects.
[10:23] <spiv> And SQLObject's cache doesn't help, because it's keyed by the id column, but __getitem__ looks up by the code column.
[10:24] <spiv> (But code is marked as a unique column, so maybe it's not hard to make SQLObject a little smarter here)
[10:40] <daf> spiv: aha
[10:40] <daf> spiv: yes, that seems like a nice optimisation to make
[10:41] <daf> spiv: I noticed on the sqlobject tracker on sourceforge that you've been the most active but reporter of late :)
[10:46] <daf> s/but/g
[10:46] <daf> grr
[10:46] <daf> s/but/bug/
[10:49] <cprov> daf: Does https://rosetta.warthogs.hbd.com/ still working ?
[10:49] <lalo> (not really DHM, more like "deep estimate mode", but that doesn't exist ;-) you get my point)
[10:51] <daf> cprov: apparently not :)
[10:51] <cprov> daf: tks ...
[10:54] <daf> cprov: try now
[10:55] <kiko> daf, how is that updated?
[10:55] <daf> kiko: basically:
[10:55] <cprov> daf: really tks now :)
[10:55] <daf> while true:
[10:55] <daf>     update launchpad
[10:55] <daf>     start launchpad
[10:55] <daf>     sleep 30m
[10:55] <daf>     kill launchpad
[10:55] <daf> 
[10:56] <daf> problem is, it stops when starting launchpad fails
[10:56] <daf> usually because of a bad commit
[10:56] <daf> I should probably make it more fault-tolerant
[10:57] <daf> by the way, what do the Soyuz team think of their logo?
[10:57] <kiko> yeah.
[10:57] <kiko> I like it, at least. :)
[10:58] <cprov> I like it too :)
[10:58] <daf> thanks :)
[10:59] <kiko> you're the unknown author?!
[10:59] <kiko> "made in wales<tm>"?
[10:59] <kiko> "proudly made in wales" perhaps
[11:00] <daf> guilty as charged :)
[11:00] <daf> actually, made in Mark's flat...
[11:00] <kiko> nice going
[11:00] <spiv> Yeah, it's good :)
[11:00] <daf> actually, Wales has been dry and sunny
[11:01] <daf> weird
[11:04] <lalo> we have quite a few txt files in our source tree - shouldn't we get rid of them?
[11:04] <daf> why?
[11:04] <cprov> daf: btw, can you update the current DB used on https://rosetta... ?
[11:05] <daf> > find -name '*.txt'
[11:05] <daf> ./scripts/rosetta-cmdline.txt
[11:05] <daf> ./no-notes-yet.txt
[11:05] <daf> ./poexport.txt
[11:05] <daf> no-notes-yet is a bit old, but still pertinent
[11:05] <cprov> daf: just wait my last commit on arch-commits ... 
[11:05] <daf> cprov: sure
[11:05] <lalo> the ones that are pertinent should be in the wiki, no?
[11:05] <daf> cprov: ok, let me know when
[11:05] <lalo> in fact I think they all are
[11:06] <daf> poexport.txt isn't
[11:06] <lalo> amazing... we don't have code to export templates at all :-P
[11:07] <cprov> daf: that's it .. I'm becoming borring :)
[11:07] <daf> poexport.txt (in theory, anyhow) is implementation documentation, and therefore belongs with the implementation
[11:07] <daf> lalo: I was thinking of asking you to write a poimpot.txt
[11:07] <daf> something code-oriented rather than requirements-oriented
[11:07] <lalo> well, if there is such a thing as docs that belong in the source tree, I'll move them all into their own subdir
[11:08] <daf> that's fine
[11:08] <daf> doc/
[11:08] <daf> ?
[11:08] <lalo> docs alongside code look awkward to me :-)
[11:08] <lalo> doc or docs - I think since we have "tests", "templates", "scripts" then we should have "docs"
[11:09] <daf> the idea is that it's easier to keep both in sync when you have them in the same place
[11:09] <daf> (code and docs)
[11:09] <daf> lalo: either is fine -- I was probably thinking of /usr/share/doc or something
[11:10] <daf> cprov: done
[11:11] <lalo> and - are we supposed to have code to export a template?
[11:11] <lalo> I honestly don't remember, but I thought we did have it and we don't
[11:11] <cprov> daf: i would say done now, thanks anyway 
[11:12] <daf> cprov: oh, oops :)
[11:13] <daf> cprov: right, done again :)
[11:14] <cprov> daf: it rocks :)
[11:15] <daf> cprov: you're welcome
[11:26] <lalo> daf: just mailed the launchpad list
[11:27] <kiko> lalo, ns estamos de mal ou seu email quebrou? :)
[11:28] <lalo> kiko: doesn't look like we're on the same charset
[11:29] <daf> lalo: obrigado
[11:29] <lalo> daf: de nada
[11:30] <kiko> lalo, or on the same brainwavelength apparently