[12:33] <mpt> "I will be good for fixing bugs."
[12:33] <matsubara> mpt: launchpad should be open source?
[12:34] <mpt> matsubara, what? :-)
[12:35] <matsubara> mpt: the bug where you read that.
[12:35] <mpt> No, I read that in bug 44
[12:35] <Ubugtu> Malone bug 44 in rosetta "Translations should be searchable" [High,Confirmed]  http://launchpad.net/bugs/44
[12:36] <mpt> An amusing typo, that's all
[12:37] <matsubara> oh I'm confusing the bugs. I guess I've been reading too many reports lately.
[12:39] <mpt> heh
[01:21] <Ubugtu> New bug: #62696 in soyuz "Task headers in Packages files do not match seeds exactly" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62696
[01:37] <kiko-afk> mpt, ping?
[01:37] <mpt> kiko-afk, pong
[01:37] <kiko-afk> mpt, you know helpers.msgid_html?
[01:38] <kiko-afk> I think you changed that when fixing the rosetta issue bug 46?
[01:38] <Ubugtu> Malone bug 46 in rosetta ""special symbols" when people copy-paste text from original to translation" [High,Fix committed]  http://launchpad.net/bugs/46
[01:42] <kiko-afk> mpt?
[01:59] <mpt> kiko-afk, yes
[02:05] <Ubugtu> New bug: #62702 in launchpad "Launchpad needs a privacy policy" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62702
[02:15] <yarddog> can someone help me with merging two accounts with one email address not accessable any longer?
[02:16] <yarddog> i have tried the email list as i was referred to, i have tried the launchpad support site, and now here
[02:16] <yarddog> anyone?
[02:17] <yarddog> "you can contact SteveA or kiko on #launchpad at irc.freenode.net and they will be able to merge your accounts."
[02:18] <yarddog> ive been trying to remedy this for a week
[02:18] <yarddog> sorry if i seem agitated but i think a week is long enough for this
[02:20] <kiko-afk> mpt, so that code appears to be on crack
[02:20] <kiko-afk> mpt, expand_rosetta_tabs is only used there -- why are you redoing the replacement with a different replacement?!
[02:20] <kiko-afk> mpt, can you email me about this so I can sort it out in the morning?
[02:20] <kiko-afk> thanks.
[02:21] <mpt> expand_rosetta_tabs??
[02:22] <mpt> Did I even touch that code?
[02:23] <kiko-afk> mpt, no, but you should have.
[02:23] <mpt> heh
[02:23] <kiko-afk> the code you change does something like
[02:23] <kiko-afk> replace("a", "b")
[02:23] <kiko-afk> replace("b", TranslationConstant.X)
[02:23] <kiko-afk> which is, well.. :)
[02:24] <mpt> ok, I'll mail you a reminder
[02:25] <kiko-afk> thanks, I'm so tired and just noticed this
[02:25] <kiko-afk>  16 files changed, 1357 insertions(+), 1484 deletions(-)
[02:25] <kiko-afk> whew
[02:25] <kiko-afk> this was actually not as bad as I thought it would be.
[02:25] <kiko-afk> of course, the tests probably don't pass :-)
[02:35] <mpt> kiko-afk, are you helping yarddog?
[02:35] <kiko-afk> oh
[02:35] <kiko-afk> no!
[02:35] <kiko-afk> yarddog, hey?
[02:35] <kiko-afk> yarddog, which are your accounts?
[02:36] <kiko-afk> yarddog, I didn't see a ticket filed by you, and nowhere did you say which two accounts needed to be merged, which is why I couldn't help you before.
[02:37] <yarddog> i filed a ticket just now
[02:37] <kiko-afk> yarddog, what's the ticket number
[02:37] <yarddog> 1911
[02:38] <kiko-afk> just like razor
[02:40] <yarddog> it seems that 'yarddog' is under the gmail address and 'yarddog2' is under the current account
[02:46] <kiko-afk> yarddog, one sec.
[02:46] <yarddog> ok
[02:49] <yarddog> thank you kiko-afk 
[02:50] <kiko-afk> most welcome
[02:50] <kiko-zzz> time to catch those zs now
[04:16] <mpt> spiv, ping
[04:20] <skaller> hi, I'm trying to figure out how to link Launchpad bugtracker to upstream sourceforge bugtracker for my product
[04:22] <skaller> any hints how to do that? do i need to create a team or something?
[04:22] <spiv> mpt: pong
[04:24] <jamesh> skaller: at the moment, you'll need to create a bugtracker object for your sf project's bug tracker
[04:25] <skaller> ok .. how does that relate to the existing package?
[04:25] <jamesh> skaller: go to https://launchpad.net/malone/bugtrackers/+newbugtracker and use a URL like http://sourceforge.net/tracker/?group_id=$GROUPID&atid=$ATID
[04:25] <jamesh> you can then link bugs to that tracker
[04:26] <jamesh> We should clean this up, since spiv found a way of getting SF bugs without knowing the groupid/atid
[04:27] <skaller> hey, the ability to do this kind of linkage at all is very superior!
[04:27] <jamesh> I'm just saying that our current handling of SF bug links sucks :)
[04:28] <skaller> sure, but i'm saying don't feel to bad about it :)
[04:28] <skaller> you ever tried to get support from microsoft?
[04:30] <jamesh> can't say I've tried directly.
[04:30] <skaller> hmm .. now I can't figure out how to get the groupid/atid from sf :)
[04:30] <jamesh> skaller: pull up the bug you want to link to and look at the URL
[04:31] <skaller> there's no bug .. but I found the tracker id now thanks
[04:31] <skaller> http://sourceforge.net/tracker/?group_id=28597&atid=394143
[04:31] <skaller> I get that URL, does that see right?
[04:32] <jamesh> yep
[04:33] <jamesh> skaller: SF has this great system where they identify each bug by three numbers.  You generally need to get all three numbers right to look at a bug
[04:33] <skaller> oops now I'm confused, which field does that URL go to
[04:34] <jamesh> "Base URL"
[04:35] <skaller> so for a name I might say "Felix upstream"?
[04:35] <skaller> Felix is the package name
[04:35] <skaller> ah .. 'felix-upstream"
[04:35] <jamesh> or "felix-bugs"
[04:36] <skaller> not to be confused with ubuntu and debian package management tho ..
[04:37] <jamesh> It is just used to differentiate it from other registered external bug trackers
[04:37] <skaller> yeah, ok, its submitted
[04:37] <skaller> now I need to link it to the package?
[04:39] <jamesh> at the moment you can't link from a bug tracker to a product.  You should be able to in the next rollout (about a fortnight from now)
[04:40] <skaller> ok more confusion: felix is an existing package in ubuntu
[04:40] <jamesh> ah.
[04:40] <jamesh> have you registered it as a product in Launchpad?
[04:40] <skaller> no not yet
[04:40] <skaller> I thought I'd ask for advise before making a mess
[04:40] <jamesh> https://launchpad.net/products/+new <- you can do that here.
[04:41] <skaller> (so i could share the blame after making the mess :)
[04:41] <jamesh> after that, it is possible to provide a link between the Ubuntu package and the upstream product
[04:42] <skaller> ok one sec .. doing the 'description' thing :)
[04:42] <jamesh> take your time.
[04:43] <mpt> spiv, I need a couple of months' of raw traffic logs from launchpad.net. Do you know how I can get them?
[04:43] <mpt> (sorry for the slow response-to-pong)
[04:43] <skaller> kak .. name/display name/title/summary/description .. all asking for the same information in more and more detail
[04:43] <jamesh> mpt: rt
[04:44] <jamesh> skaller: the "name" is a short lower-case no-spaces name used in the URLs.  "display name" can have spaces, "title" is used in page titles, etc
[04:44] <jamesh> summary and description aren't that different ...
[04:47] <mpt> jamesh, argh. I made an rt request yesterday, but Steve said I should contact you or spiv instead
[04:48] <jamesh> mpt: I think only the admins have access to the apache logs, but I might be mistaken
[04:49] <skaller> ok made a product
[04:49] <jamesh> skaller: okay.  Launchpad has the concept of "product series", which represent separate lines of development
[04:50] <jamesh> by default, your product has a single series called "trunk"
[04:50] <skaller> yup
[04:50] <jamesh> if you make your releases off the tip of CVS or subversion, then you should link the trunk series to the Ubuntu package
[04:50] <skaller> corresponding to svn trunk?
[04:51] <jamesh> pretty much
[04:52] <skaller> ouch ..
[04:52] <jamesh> on the product series page (e.g. https://launchpad.net/products/felix/trunk), there is a "Link to Ubuntu Package" link, which takes you to a form where you can make the association
[04:52] <skaller> the Debian packaging goes in another place though
[04:53] <skaller> it's maintained by a separate Debian group
[04:53] <skaller> is that relevant?
[04:53] <jamesh> currently we don't import information about individual debian packages into launchpad, so it isn't.
[04:54] <skaller> ok .. so is the package name 'felix' or does it need a version number ?
[04:55] <jamesh> if the source package name is "felix", then that's all you need.
[04:55] <skaller> ok .. thanks .. now i need the svn name .. 
[04:56] <jamesh> you looking at the "edit source" form now?
[04:56] <skaller> Upstream source import
[04:56] <skaller> ?
[04:56] <jamesh> yeah
[04:57] <skaller> sf says:  svn co https://svn.sourceforge.net/svnroot/felix felix
[04:57] <jamesh> you only need to fill in this form if you want us to import your code into a Bazaar branch
[04:57] <skaller> ack, what's a Bazaar?
[04:57] <jamesh> http://www.bazaar-vcs.org
[04:58] <mpt> jamesh, on a completely separate subject, my development machine will soon run out of disk space. Which of these make sense to do? (1) Delete the directories for old branches in my repository. (2) Delete everything except the .bzr/ directory in those branches. (2) Delete the sourcecode/ directory from those branches branches that had entire copies of it.
[04:58] <mpt> (er, make that last (2) -> (3) :-)
[04:59] <jamesh> mpt: you shouldn't need to keep working trees around for your old branches
[04:59] <jamesh> keep your old branches (which should each take about .3MB), but you don't need to keep old working trees
[05:01] <mpt> So what exactly do you mean by "keep your old branches"?
[05:01] <mpt> Just the .bzr/ subdirectory?
[05:02] <jamesh> mpt: can you describe your development setup?  I want to make sure I don't tell you to do something destructive
[05:02] <mpt> In ~/hacking/lp/ I have a single subdirectory for each branch
[05:03] <jamesh> e.g. are you using lightweight checkouts from a local repo? are you using independent branches? etc
[05:03] <mpt> ~/hacking/lp/2005-12-layout, ~/hacking/lp/2006-06-menus, and so on
[05:03] <mpt> I am not using lightweight checkouts
[05:03] <mpt> but I am using a local repository
[05:03] <jamesh> okay.  where is your repository?
[05:04] <mpt> ~/hacking/lp/.bzr/repository/
[05:04] <jamesh> so if you run "bzr info" in ~/hacking/lp/2005-12-layout", it lists ~/hacking/lp as the repository?
[05:05] <mpt> no
[05:05] <mpt> probably because that wasn't one of the branches I was working on when we switched to repositories
[05:06] <mpt> so I didn't switch that one.
[05:06] <mpt> "Format <RepositoryFormat6> ... is deprecated"
[05:06] <jamesh> okay.  For one of your newer branches, can you verify that it is using the repository?
[05:07] <mpt> Yes, my trivial/ branch is using it
[05:07] <skaller> when you're read jamesh yell?
[05:08] <mpt> oh
[05:08] <mpt> A newly-created branch isn't using it
[05:08] <mpt> that's bad
[05:09] <mpt> 2006-09-bug-46/: "branch root: file:///home/mpt/hacking/lp/2006-09-bug-46/"
[05:09] <jamesh> this might be why you are running out of disk space :)
[05:10] <mpt> 29.8 GB of Launchpad code
[05:10] <mpt> So, first, stop the bleeding
[05:10] <mpt> What is the proper way for me to be creating a new branch, possibly offline, given a ~/hacking/lp/rocketfuel copy of rocketfuel?
[05:10] <jamesh> on my system I've got about ~270MB for my repository, some amount for my rocketfuel-built tree and ~ 150MB for each working tree
[05:11] <jamesh> what do you currently do when you want to start a new branch?
[05:11] <mpt> cp -a
[05:11] <skaller> lol
[05:12] <jamesh> mpt: okay.  If you copy an independent branch with "cp -a", you'll end up with an independent branch
[05:14] <skaller> managing shared development efforts is more work that hacking the code :)
[05:14] <jamesh> mpt: the workflow I recommend is here: https://launchpad.canonical.com/WorkingWithSharedRepositories
[05:15] <jamesh> mpt: i.e. keep your branches separate from your working trees.
[05:15] <skaller> The Launchpad development wiki is not available to the public. 
[05:16] <mpt> jamesh, are you constantly cd-ing between ~/src/lp/whatever to make run and to run tests, and ~/repo/canonical/whatever to do commits and pushes?
[05:16] <jamesh> mpt: running "bzr commit" or "bzr push" in the checkout performs those operations on the branch
[05:17] <jamesh> mpt: I usually only change dir to my repository dir when creating a new branch
[05:17] <mpt> ok
[05:17] <jamesh> mpt: the benefit of this setup is that provided there are no uncommitted changes, I can blow away the checkout
[05:18] <mpt> ok, so sanity-check this for me
[05:18] <mpt> mkdir ~/hacking/lp-repo && mv ~/hacking/lp/.bzr ~/hacking/lp/
[05:18] <mpt> urg, I'll try that again
[05:18] <mpt> mkdir ~/hacking/lp-repo && mv ~/hacking/lp/.bzr ~/hacking/lp-repo/
[05:19] <mpt> Moving my repository to a separate directory, leaving all the existing branches in place
[05:19] <jamesh> if you have any branches actually using that repo, you'll have problems.
[05:19] <mpt> darn.
[05:19] <mpt> Should I make a new repository then?
[05:20] <jamesh> creating a new repo would be best
[05:20] <jamesh> copying the old repo would be second best
[05:20] <mpt> Which one will mean I'm not stuck permanently with 29.8 GB of branches? :-)
[05:21] <jamesh> if you are mainly interested in freeing up disk space rather than changing your work flow, try this:
[05:21] <mpt> Changing my workflow is fine
[05:21] <jamesh> (1) create the repo with "bzr init-repo ~/hacking/lp-repo"
[05:22] <jamesh> (2) for a branch you don't care about, do "cd ~/hacking/lp-repo; bzr branch ~/hacking/lp/$BRANCHNAME"
[05:22] <jamesh> (3) remove ~/hacking/lp/$BRANCHNAME
[05:22] <spiv> mpt: Yeah, I don't have any direct access to the launchpad.net traffic logs that I know of...
[05:23] <spiv> mpt: (sorry for the lag, was in transit to poolie's)
[05:23] <jamesh> now before doing this, make sure the branch you are copying is "Meta directory format 1"
[05:23] <skaller> hey jamesh, thanks for help .. think it's all set up now
[05:23] <jamesh> if you branch a really old branch, it won't make use of the repository
[05:24] <mpt> ok, I want to change my workflow too
[05:24] <jamesh> skaller: cool.
[05:24] <mpt> because currently I'm having to do sketchy stuff with ln -s ../rocketfuel/sourcecode ./sourcecode
[05:24] <skaller> off to do some actual programming .. :)
[05:25] <mpt> (so as not to have a copy of sourcecode/ in every new branch)
[05:25] <jamesh> mpt: once you've created the branch in your repo, you can set up your working trees using the steps listed in the "Creating Working Trees" section on that wiki page
[05:26] <mpt> ok, thanks jamesh
[05:27] <jamesh> mpt: I've got a script I use to help set up the sourcecode/ trees in my lightweight checkout too
[05:28] <jamesh> it does lightweight checkouts of my rocketfuel-built tree
[06:35] <Ubugtu> New bug: #62717 in blueprint "Anybody can target specs at milestones" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62717
[08:30] <SteveA> morning
[08:32] <SteveA> lifeless: isn't he some contemporary philosopher with new-age leanings?
[08:32] <lifeless> SteveA: no idea ;)
[08:33] <SteveA> why did you ask?
[08:33] <SteveA> actually, that's Ken Wilbur
[08:33] <lifeless> I think I was confused about which list is which
[08:41] <jamesh> lifeless: fyi: I've put branches to get cscvs and launchpad tests passing with bzr-0.11 for review
[08:46] <lifeless> jamesh: thanks. Can you bring them to ddaa's attention ?
[08:46] <jamesh> lifeless: just replied to his launchpad list post where he asked me to look at it.  I'll ping him when he gets up.
[08:47] <SteveA> jamesh: what's the "null revision" ?
[08:47] <jamesh> SteveA: revision 0
[08:47] <lifeless> mmaybe
[08:48] <SteveA> the cscvs changes look fine to me, although I don't really know the bzr api so I can't be a good reviewer
[08:48] <lifeless> revision 0 is not always == NULL_REVISION
[08:48] <SteveA> how is it special?
[08:48] <lifeless> NULL_REVISION is the implicit origin of the revision graph
[08:48] <lifeless> it is misnamed
[08:48] <lifeless> and will be renamed in bzr at some point to be EMPTY_REVISION
[08:49] <jamesh> SteveA: the cscvs code was trying to decide whether the working tree contained changes, which it defined as (a) having any changes or (b) having pending merges
[08:49] <SteveA> not GRAPH_ORIGIN ?
[08:49] <lifeless> SteveA: unlikely
[08:49] <SteveA> I mean, EMPTY_REVISION seems about as opaque to me as NULL_REVISION
[08:49] <lifeless> SteveA: theres a bunch of other context 
[08:50] <lifeless> SteveA: which you dont have right now, in that context EMPTY is likely better
[08:50] <SteveA> lifeless: do you know how to make irssi not go fucky when scott leaves a channel?
[08:50] <jamesh> SteveA: normally a working tree has the last revision of the branch as its first parent revision, and any pending merges are second, third, etc parents
[08:50] <stub> lifeless: it looks like a bzr merge has hung under pqm. Want to have a look, or should I just kill it?
[08:50] <lifeless> jamesh: tree.changes_from(tree.basis_tree()).has_changes
[08:50] <lifeless> stub: I'll look
[08:51] <jamesh> lifeless: the cscvs code is doing both that and checks for pending merges
[08:52] <Keybuk> SteveA: use a better IRC client that understands utf-8?
[08:52] <lifeless> Keybuk: irssi understands utf8
[08:52] <SteveA> Keybuk: yes.  apparently irssi does, but there's an interesting combination of term settings and irssi settings.
[08:52] <lifeless> stub: make sure you are using a utf8 terminal
[08:53] <SteveA> so right now, some lithuanian characters I can type, others I can read, and still others I can neither read nor write.
[08:53] <lifeless> erm, stub, stevea
[08:53] <jamesh> lifeless: do the parent_ids/pending_merges check is not necessary?
[08:53] <jamesh> s/do/so/
[08:53] <lifeless> stub: you are good to go
[08:54] <lifeless> stub: I've killed the job, the rest will proceed as normal
[09:03] <lifeless> jamesh: one sec
[09:04] <jamesh> lifeless: would a more correct has_changes() implementation be to check if the parent_ids list differed from just the basis tree revision ID?
[09:09] <lifeless> jamesh: yes, delta should be fixed
[09:09] <lifeless> jamesh: right now you do need to check parent_ids
[09:10] <lifeless> pending_merges is a deprecated interface: just left.get_parent_ids() != right.get_parent_ids() or tree.changes_from(tree.basis_tree()).has_changes() is enough
[09:11] <jamesh> what are left and right in the above?
[09:11] <jamesh> if one is the working tree and the other the basis tree, won't they always have different parent IDs?
[09:12] <lifeless> blech. 
[09:13] <lifeless> tree.changes_from(tree.basis_tree()).has_changes() or len(tree.get_parent_ids()) > 1
[09:13] <jamesh> okay.  That'
[09:13] <jamesh> s what I have now.
[09:14] <sivang> morning
[09:14] <jamesh> but it was failing for an empty tree that had a ghost parent tree added
[09:15] <jamesh> since it was picking an empty tree as basis and len(tree.get_parent_ids()) == 1
[09:17] <lifeless> ah right. do we have cscvs tests that need ghosts ?
[09:17] <lifeless> seems strange that we'd need that
[09:17] <lifeless> baz-import should be the only thing needing such tests offhand
[09:17] <lifeless> (and point of fact: hwne the left most parent is a ghost then changes *have* occured.
[09:18] <lifeless> so its correct to show it as changed
[09:18] <jamesh> lifeless: I doubt it occurs in real use, but a test exercised that case
[09:18] <jamesh> lifeless: I changed the test to do a commit to the branch first
[09:18] <lifeless> sounds like the test is/was faulty though
[09:21] <jamesh> the other way to handle the parent check would be (1) call get_parent_ids(), (2) remove the basis tree's revision ID from the list and (3) check if the list is non-empty
[09:24] <SteveA> morning malcolm
[09:24] <malcc> Morning
[09:44] <SteveA> goedemorgen carlos
[09:45] <carlos> it sounds like German but I guess it's Lithuanian, isn't it?
[09:45] <carlos> SteveA: good morning for you too ;-)
[09:49] <SteveA> no.  it is Dutch.
[09:50] <SteveA> Lithuanian would be Labas rytas
[09:51] <sivang> so rytas is morning ?
[09:51] <carlos> I see
[09:51] <SteveA> it is
[09:51] <SteveA> it also means "the east"
[09:52] <sivang> ah :-)
[09:52] <sivang> so Labas rytas is something like "hi morning" or so? (recalling Labas is like 'hi')
[09:52] <raphink> Labadiena :)
[09:53] <SteveA> "labas" is an old word for "good"
[09:53] <SteveA> it exists in modern lithuanian just as certain greetings, and in the word for "very"
[09:53] <SteveA> the modern word for "good" is derived from russian
[09:54] <sivang> ah, how does it fit in then in "Labas SteveA" ? it just becomes the 'hi' greeting?
[09:54] <raphink> xorosho?
[09:54] <raphink> shalom sivang btw :)
[09:54] <sivang> raphink: hey raphink ;)
[09:54] <raphink> ma shlomkha ?
[09:54] <sivang> heh
[09:55] <sivang> raphink: all is good , and you ?
[09:55] <raphink> tov :)
[09:55] <raphink> I'm at work ;)
[09:55] <raphink> anyone knows why the NEW queue is stuck?
[09:56] <sivang> raphink: did you meet Shahar recently? he's still in france
[09:56] <raphink> oh really?
[09:56] <raphink> didn't see him in the last 2 months
[09:57] <sivang> raphink: I guess his mostly in Paris these days
[09:57] <raphink> ah ok
[09:57] <raphink> and I'm not
[10:34] <carlos> danilos: hi
[10:34] <danilos> carlos: hi
[10:34] <carlos> danilos: did you have a chance to look at my branch?
[10:34] <danilos> carlos: still having connection problems :(
[10:35] <carlos> danilos: :-(
[11:50] <Ubugtu> New bug: #61528 in rosetta "kdebluetooth ignores translations from Rosetta" [Undecided,Fix released]  http://launchpad.net/bugs/61528
[11:54] <danilos> jordi: ping
[01:19] <danilos> mpt: ping
[01:19] <malcc> Our bug number 1 is linked on reddit and climbing the front page, we may want to watch out for any load issues
[01:22] <shawarma> How do I create a new remote bugtracker? 
[01:23] <jordi> danilos: hey
[01:23] <jordi> danilos: I've been on a all morning long meeting
[01:23] <jamesh> shawarma: https://launchpad.net/malone/bugtrackers/+newbugtracker
[01:23] <danilos> jordi: ok, so lets leave the KDE stuff for after the LP meeting
[01:24] <jordi> danilos: ok.
[01:24] <carlos> danilos: and GNOME
[01:25] <danilos> carlos: that's right ;)
[01:25] <shawarma> jamesh: Thanks.
[01:25] <shawarma> jamesh: Is the "contact details" field supposed to be machine parsable somehow? If yes, what is the format?
[01:25] <jamesh> shawarma: it is free text
[01:26] <shawarma> jamesh: Ok, thanks.
[01:27] <carlos> wow
[01:27] <carlos> carlos@aragorn:~/Desktop/ooo-edgy-2006-09-28$ du -hs .
[01:27] <carlos> 916M    
[01:28] <carlos> that's a full export of OO.org translations for Edgy
[01:28] <jamesh> carlos: it'd be a bit smaller if you trimmed infrequently used languages
[01:28] <jamesh> such as languages other than english
[01:28] <carlos> jamesh: or Spanish ;-)
[01:31] <stub> Meeting in 29 mins
[01:46] <LeeJunFan> us.archive.ubuntu.com is broken, apache not answering connections apparently, haven't tried ftp - but the host seems up.
[01:47] <Znarl> LeeJunFan : OK, I'll fix that.
[01:47] <LeeJunFan> Znarl: thanks.
[01:52] <ddaa> mpt: dude, give me a bit more than 8 hours forewarning to set up a meeting
[01:52] <ddaa> especially when those 8 hours fall in my sleep hours :(
[01:53] <jamesh> hi ddaa
[01:58] <ddaa> mpt: ping
[02:00] <stub> Meeting time
[02:00] <matsubara> me
[02:00] <kiko-zzz> me
[02:00] <danilos> me
[02:00] <stub> me
[02:00] <salgado> me
[02:00] <malcc> me
[02:00] <jordi> me
[02:00] <spiv> me
[02:01] <jamesh> me
[02:01] <BjornT> me
[02:01] <carlos> me
[02:01] <spiv> lifeless sends his apologies.
[02:01] <bradb> me
[02:01] <ddaa> me
[02:01] <SteveA> me
[02:01] <niemeyer> me
[02:01] <SteveA> mpt will be 5-10 mins late.  sends apologies
[02:01] <cprov> me
[02:02] <flacoste> me
[02:03] <danilos> is my connection lagging, or is the meeting not happening?
[02:03] <kiko> carlos, only 7 tests fail!
[02:03] <stub> danilos: I think SteveA is preparing
[02:03] <ddaa> danilos: your connection is lagging, but since it's lagging you won't see that before you see that the meeting has started already
[02:03] <stub> Who is up to date with their activity reports?
[02:03] <malcc> me
[02:03] <danilos> stub: ah, ok
[02:03] <ddaa> up to date
[02:03] <danilos> behind
[02:03] <malcc> up to date
[02:03] <bradb> up to date
[02:03] <spiv> up to date
[02:03] <BjornT> up to date
[02:03] <jamesh> behind
[02:04] <flacoste> up to dat
[02:04] <salgado> behind
[02:04] <stub> Looks like I missed two days, so I need to interrogate my log
[02:04] <matsubara> i'm behind
[02:04] <carlos> behind
[02:04] <SteveA> behind
[02:05] <kiko> I'm behind, but if I was up to date all it would say would be "REFACTORING ROSETTA VIEWS TO DEATH"
[02:05] <stub> == Agenda ==   * Roll call  * Agenda  * Next meeting  * Activity reports  * Actions from last meeting  * Oops report (Matsubara)  * Bug report report (mpt)  * Production and staging (Stuart)  * Launchpad 1.0 status reports  * Sysadmin requests ----  * (other items) ----  * Keep, Bag, Change  * Three sentences  
[02:06] <stub> == Actions from last meeting ==   * SteveA to put up a wiki page for the launchpad project to note disaster scenarios on, and mail the list about it  * SteveA to write up what needs doing to implement `__eq__`, `__ne__`, and `__hash__` for database objects
[02:06] <cprov> up to date
[02:06] <stub> SteveA: hows it going?
[02:06] <SteveA> same as last week :-(
[02:06] <SteveA> I'll do them after this meeting.
[02:07] <kiko> you said that last week :)
[02:07] <jordi> I'm one week behind
[02:07] <danilos> stub: did you reorder agenda items, or did you miss the next meeting one accidentally?
[02:07] <stub> carlos, jamesh, SteveA, kiko: at least two weeks running late!
[02:07] <danilos> or, my connection blurped
[02:08] <danilos> stub: me too :(
[02:08] <stub> danilos: No - I suck
[02:08] <SteveA> kiko: I did not.  I said keep them on the agenda for the next meeting. :-)
[02:08] <stub> Next meeting - same time, same channel?
[02:08] <kiko> stub, I'll be back in the groove this week. I've managed to fix the issues that I thought I would never do!
[02:08] <SteveA> I will be on a vacation day next week
[02:08] <SteveA> although I may be here for the 45 minutes for the meeting
[02:09] <stub> SteveA: Please appoint a replacement chair
[02:09] <stub> SteveA: And send a status for those action items before you go on leave
[02:09] <SteveA> steve ballmer threw the last one across the room
[02:09] <SteveA> ok
[02:09] <stub> So same time, same channel next week
[02:10] <mpt> Hi guys, sorry I'm late, I'm up to date with activity reports, but I haven't prepared the bug report report
[02:10] <salgado> eh?
[02:10] <SteveA> that's a negative bug report report report
[02:10] <matsubara> me you mean
[02:10] <stub> erm... matsubara
[02:10] <matsubara> anyway
[02:10] <matsubara> Today's oops report is about bugs 58220, 61153, 62466, 28697, 46591
[02:10] <Ubugtu> Malone bug 58220 in launchpad "When an error occurs processing a request another oops is recorded because there's no interaction set up." [Medium,Confirmed]  http://launchpad.net/bugs/58220
[02:10] <Ubugtu> Malone bug 62466 in malone ""Untriaged" to "Undecided" rename broke search form URLs" [Undecided,Confirmed]  http://launchpad.net/bugs/62466
[02:10] <Ubugtu> Malone bug 28697 in malone "Bug lists should show current search filter" [Medium,Confirmed]  http://launchpad.net/bugs/28697
[02:10] <Ubugtu> Malone bug 46591 in launchpad "Serving everything under SSL causes slowdown" [Medium,Confirmed]  http://launchpad.net/bugs/46591
[02:10] <matsubara> Basically when bug 58220 is triggered, the user ends up with a message like: "IntegrityError; A server error occurred." instead of the nice OOPS page saying that something went wrong. Any volunteers?
[02:11] <matsubara> Stuart can you take care of bug https://launchpad.net/products/launchpad/+bug/61153?
[02:11] <matsubara> bradb, could you prioritize bug 28697?
[02:11] <matsubara> stub: ^
[02:11] <bradb> matsubara: sure
[02:11] <stub> matsubara: ok
[02:11] <kiko> bradb, mmmm. maybe resurrect your patch and hand it off for updating and landing?
[02:12] <matsubara> Bug 62466. Any suggestions how to improve this kind of situation. Maybe fixing bug 1331 would improve it. Or perhaps display one of those BrowserNotification messages saying that the given search parameter was deprecated and offer a alias for some time after the change. Is this feasible?
[02:12] <Ubugtu> Malone bug 62466 in malone ""Untriaged" to "Undecided" rename broke search form URLs" [Undecided,Confirmed]  http://launchpad.net/bugs/62466
[02:12] <Ubugtu> Malone bug 1331 in malone "Allow recording and use of canned searches" [Medium,Confirmed]  http://launchpad.net/bugs/1331
[02:12] <stub> matsubara: Please feel free to prioritize it as appropriate ;)
[02:12] <kiko> matsubara, I think we just need to be more careful when changing search form parameters.
[02:12] <bradb> matsubara: how did bug 28697 make the oops report?
[02:12] <Ubugtu> Malone bug 28697 in malone "Bug lists should show current search filter" [Medium,Confirmed]  http://launchpad.net/bugs/28697
[02:12] <kiko> matsubara, raisining UFD is okay
[02:13] <matsubara> stub: I felt scared when you said that could be something evil happening, so I believe you understand the implications of that bug better than me :)
[02:13] <stub> matsubara: Something evil we are happily defending against, so no need to be scared.
[02:13] <stub> (just an average day on the 'Net)
[02:13] <bradb> kiko: yeah, could see how much conflict the search filter patch is in right now
[02:14] <matsubara> bradb: it's not really an oops but it's more like: let's keep users happy and don't confuse them
[02:14] <SteveA> so
[02:14] <SteveA> we could extend the concept of UFD
[02:14] <stub> UFD?
[02:14] <bradb> matsubara: i think it belongs on mpt's report, not on an oops report, fwiw.
[02:14] <matsubara> stub: Unexprected Form Data
[02:14] <SteveA> to allow you to raise UFD(old='untriaged', new='undecided')
[02:14] <matsubara> Unexpected even
[02:14] <danilos> uncertainity, fear, doubt ;)
[02:14] <SteveA> and have the UFD error page present a reasonable notice about that
[02:15] <matsubara> bradb: there will be no mpt report today. :)
[02:15] <bradb> i know!
[02:15] <mpt> there might just be
[02:15] <stub> Ok - mpt's bug report!
[02:15] <mpt> okie dokie
[02:15] <matsubara> wait
[02:15] <SteveA> you could even have a number of renamings / deprecations in the UFD, and have it look in the request to see which are important
[02:15] <stub> doh!
[02:16] <mpt> matsubara still has the floor
[02:16] <matsubara> Bug 46591, how difficult is to use SSL only on authentication? Bug 60803 might be related to it.
[02:16] <Ubugtu> Malone bug 46591 in launchpad "Serving everything under SSL causes slowdown" [Medium,Confirmed]  http://launchpad.net/bugs/46591
[02:16] <Ubugtu> Malone bug 60803 in launchpad "Launchpad has been slowing down recently." [Undecided,Needs info]  http://launchpad.net/bugs/60803
[02:16] <stub> matsubara: That is a post 1.0 feature
[02:16] <SteveA> the only thing we could do to speed it up is
[02:16] <matsubara> and no answer yet for the volunteer call to fix bug 58220
[02:16] <Ubugtu> Malone bug 58220 in launchpad "When an error occurs processing a request another oops is recorded because there's no interaction set up." [Medium,Confirmed]  http://launchpad.net/bugs/58220
[02:16] <SteveA> to use different host names for some content.  we do that already, though, for the librarian.
[02:17] <kiko> SteveA, but.. if it's non-SSL it still gives broken padlock.
[02:17] <SteveA> still SSL
[02:17] <kiko> matsubara, what do you need to know to fix that bug?
[02:17] <kiko> SteveA, how would that help?
[02:17] <SteveA> splitting it among different hosts allows the browser to get more in parallel
[02:17] <SteveA> there are rules in the browser about not getting much in parallel from the same host name
[02:17] <kiko> hmmm. 
[02:18] <SteveA> so, for example, we could serve CSS + JS from a different host name
[02:18] <SteveA> and that would likely speed things up
[02:18] <jamesh> although in theory HTTP pipelining should give enough speed
[02:18] <jamesh> (but it isn't usually turned on in browsers)
[02:18] <BjornT> matsubara: if no one else volunteers, i guess i could take a look at that bug. i don't think i'll have time to do it this week, though.
[02:18] <SteveA> we can easily experiement with moving fixed resources to a different hostname
[02:19] <SteveA> just have resources.launchpad.net, and a config file entry for where resources are served from 
[02:19] <SteveA> and make sure we're using appropriate links in the main template
[02:19] <SteveA> or something like that
[02:19] <matsubara> BjornT: thanks. I might try to fix it if you lend me a hand.
[02:19] <SteveA> and, seeing as zope's publisher needn't be involved in serving up resources
[02:19] <SteveA> we could even add aggressive apache cacheing to them
[02:19] <BjornT> matsubara: sure
[02:20] <SteveA> reducing the latency for serving them up
[02:20] <SteveA> so, my point is, there are things we can do that are much simpler than allowing http
[02:20] <kiko> SteveA, I suspect much much less effective though. would need to measure.
[02:20] <SteveA> that would likely make the average page load much more quickly
[02:20] <SteveA> kiko: these measures would speed up http also
[02:21] <SteveA> but I agree with the need of measuring things somehow
[02:21] <stub> I personally wouldn't bother until we can spec and implement moving most of out pages to HTTP
[02:21] <SteveA> I would bother moving resources to a different host.
[02:21] <kiko> I concur with stub, unfortunately
[02:21] <SteveA> it is simple, and I think likely an easy win
[02:21] <kiko> because the experiments I've done.. well, whatever.
[02:21] <SteveA> have you experimented with using a different host for resources?
[02:22] <mpt> There is still waste CSS I can remove.
[02:22] <mpt> Maybe 10 KB of it.
[02:22] <mpt> or 5 KB.
[02:22] <mpt> though that might not be a good priority right now.
[02:22] <kiko> SteveA, not on launchpad, but on other web projects
[02:23] <SteveA> 5-10kb is small compared to the JS spoo
[02:23] <kiko> mpt, the connection setup latency is probably worse than the 5kb :-(
[02:23] <stub> I also don't know if Bug 46591 and Bug 60803 are actually related, or if Bug 60803 is actually a client issue or not.
[02:23] <Ubugtu> Malone bug 46591 in launchpad "Serving everything under SSL causes slowdown" [Medium,Confirmed]  http://launchpad.net/bugs/46591
[02:23] <Ubugtu> Malone bug 60803 in launchpad "Launchpad has been slowing down recently." [Undecided,Needs info]  http://launchpad.net/bugs/60803
[02:23] <stub> Unfortunately, we don't have response time metrics. Something for cricket to graph I think
[02:24] <SteveA> stub: this is down to how browsers are implemented.  there is more to it than looking at a raw ssl+http stream
[02:24] <kiko> I should point out something odd
[02:25] <jamesh> that we're half way through the meeting?
[02:25] <stub> SteveA: But that would not explain a recent slowdown, as that hasn't really changed. I don't think the CSS or number of images has grown.
[02:25] <kiko> that is /local/ page loads (over http) appear to not be caching resources
[02:25] <kiko> I'm not sure why though.
[02:25] <kiko> I'll need to investigate
[02:25] <SteveA> we're not sending caching headers for them
[02:25] <SteveA> so I'm not surprised
[02:25] <flacoste> SteveA: i think funkload can be use for whole pages (html+dependencies) benchmarks
[02:26] <matsubara> stub: I'm done, btw. perhaps this discussion should be done another time since it's post 1.0 goal.
[02:26] <matsubara> thanks everyone. specially for all the comments on the slowdown thing.
[02:26] <stub> ok. We can continue discussing this after if we want to attempt a short term fix.
[02:26] <SteveA> matsubara: I'll arrange a quick experiment on staging to see if the ssl + many hsots thing will help.
[02:26] <stub> mpt's bug report is next
[02:26] <mpt> We are down to only(?) ten Critical open bugs. They are:
[02:26] <mpt>  * Bug #1558 (Export request form should check for uniqueness of entry), Critical, Confirmed, matsubara
[02:26] <Ubugtu> Malone bug 1558 in rosetta "Export request form should check for uniqueness of entry" [Critical,Confirmed]  http://launchpad.net/bugs/1558
[02:26] <mpt> matsubara, will you get that done this week?
[02:27] <kiko> isn't that fix RELEASED?
[02:27] <mpt>  * Bug 2497 (/people/*/+translations times out for prolific translators), Critical, In Progress, kiko
[02:27] <mpt>  * Bug 30602 (Timeout errors in +translate), Critical, Confirmed, kiko
[02:27] <mpt> kiko, how's 2497 going?
[02:27] <Ubugtu> Malone bug 2497 in rosetta "/people/*/+translations times out for prolific translators" [Critical,In progress]  http://launchpad.net/bugs/2497
[02:27] <matsubara> mpt: it's actually already fixed
[02:27] <Ubugtu> Malone bug 30602 in rosetta "Timeout errors in +translate" [Critical,Confirmed]  http://launchpad.net/bugs/30602
[02:27] <mpt> matsubara, cool
[02:27] <matsubara> mpt: I just need to land a test that kiko will review today. :)
[02:27] <kiko> mpt, it's being reviewed. I'll finish it beginning of next week.
[02:27] <mpt> excellent news
[02:27] <jordi> cool!
[02:27] <mpt>  * Bug 44214 (We need to add code to prevent POFiles being in the same path), Critical, In Progress, carlos
[02:27] <mpt>  * Bug 46559 (private), carlos
[02:27] <mpt>  * Bug 46982 (Rosetta does not accept correct KDE plural forms when there are more than 2), Critical, Confirmed, carlos
[02:27] <mpt> carlos, do you need to pass one of those to danilos?
[02:27] <Ubugtu> Malone bug 44214 in rosetta "We need to add code to prevent POFiles being in the same path" [Critical,In progress]  http://launchpad.net/bugs/44214
[02:27] <Ubugtu> Malone bug 46982 in rosetta "Rosetta does not accept correct KDE plural forms when there are more than 2" [Critical,Confirmed]  http://launchpad.net/bugs/46982
[02:27] <danilos> mpt: I might end up  doing 46982 anyway
[02:28] <danilos> mpt: but i t's blocked on translationimport stuff I am doing
[02:28] <mpt> danilos, ok, should I assign it to you?
[02:28] <kiko> danilos, carlos, mpt: pleeease don't conflict with my megapatch or I will die
[02:28] <carlos> mpt: 44214 is blocked on some test failing and I don't find why
[02:28] <danilos> mpt: so, nobody can do it before this is finished
[02:28] <mpt>  * Bug 48860 ("Also notified" makes difficult to unsubscribe), Critical, In Progress, bradb
[02:28] <mpt> bradb, it's hanging around like a bad smell, what's the news?
[02:28] <Ubugtu> Malone bug 48860 in malone ""Also notified" makes difficult to unsubscribe" [Critical,In progress]  http://launchpad.net/bugs/48860
[02:28] <bradb> mpt: in review
[02:28] <danilos> kiko: hum, hum, don't die before you submit it ;)
[02:29] <mpt> kiko, please at least put it up for review before you expire
[02:29] <mpt> bradb, great!
[02:29] <kiko> mpt, I did yesterday.
[02:29] <mpt> good good
[02:29] <mpt>  * Bug 48948 (dapper indices files still being regenerated but shouldn't be), Critical, Confirmed, malcc
[02:29] <mpt>  * Bug 62612 (Need a drescher disk space strategy), Critical, Confirmed, malcc
[02:29] <mpt> malcc, should cprov get one of those?
[02:29] <carlos> mpt: danilo will take a look today and I will give it a second try also today 
[02:29] <Ubugtu> Malone bug 48948 in soyuz "dapper indices files still being regenerated but shouldn't be" [Critical,Confirmed]  http://launchpad.net/bugs/48948
[02:29] <Ubugtu> Malone bug 62612 in soyuz "Need a drescher disk space strategy" [Critical,Confirmed]  http://launchpad.net/bugs/62612
[02:29] <danilos> mpt: you can reassign it to me, but anyway, carlos and I will have to deal with it, and it's not getting done in the next week (as I said, blocked on ff stuff)
[02:29] <carlos> kiko: don't worry, my bugs are not related to those views
[02:29] <malcc> mpt: No, that allocation is ok
[02:29] <mpt> ok.
[02:29] <malcc> mpt: we have a way forward now on 48948, a tweak to dsync implementation
[02:30] <mpt> And finally
[02:30] <mpt>  * Bug 54241 (We need a script or tool that prunes OOPS logs from sodium), Critical, In Progress, stub
[02:30] <Ubugtu> Malone bug 54241 in launchpad "We need a script or tool that prunes OOPS logs from sodium" [Critical,In progress]  http://launchpad.net/bugs/54241
[02:30] <mpt> stub, will that be fixed this week?
[02:30] <malcc> mpt: And the disk space one is at a discussion stage
[02:30] <carlos> danilos: I prefer that you work on OO and leave the KDE plural forms to me
[02:30] <kiko> malcc, and I have given an opinion there too! :)
[02:30] <stub> mpt: Done except for some tests. Given a favorable review, should land mid next week.
[02:30] <danilos> carlos: yeah, I am fine with it, but who is assigned on the bug is not really important in the next week or so
[02:30] <danilos> :)
[02:30] <carlos> danilos: once I finish TranslationReviews I will have time, and it should be fast once kiko finishes his work
[02:30] <mpt> I also suspect that bug 30264 and bug 31609 should be Fix Released, not Fix Committed. malcc/cprov, can you check those?
[02:30] <Ubugtu> Malone bug 30264 in soyuz "P-A-S support needs proper binary-only excludes" [Critical,Fix committed]  http://launchpad.net/bugs/30264
[02:30] <carlos> danilos: right
[02:30] <Ubugtu> Malone bug 31609 in soyuz "buildd maintainers need to be informed of build failures" [Critical,Fix committed]  http://launchpad.net/bugs/31609
[02:31] <danilos> carlos: great, thanks
[02:31] <mpt> Otherwise, that's all.
[02:31] <mpt> thanks stub.
[02:31] <mpt> And, thanks stub.
[02:31] <cprov> mpt: that's right, will update their state
[02:31] <stub>  * Production and staging (Stuart)
[02:31] <stub> Production was updated on Tuesday, with two soyuz cherry picks added since then.
[02:31] <cprov> mpt: thanks 
[02:31] <stub> I think that the current soyuz branch to be used should be documented on the LaunchpadProductionStatus wiki page - there was a delay in switching soyuz back on because I had neglected to determine this the previous day when people were online.
[02:31] <stub> Staging is still running BradB's branch for testing. As it has been a week, and AFAIK not updated at all, I suspect that the testing has not been a priority.
[02:31] <stub> We should try to keep the window when staging is not running HEAD to a minimum, and the alternative (setting up other Launchpad instances) is not nice either as it doesn't happen instantly.
[02:31] <stub> demo.launchpad.net has grown features.demo.launchpad.net for testing by the Zope community. If this keeps up, we may want to make demo.launchpadd.net a permanent feature (originally we expected to only need it for a month or three). Thanks jamesh for maintaining this.
[02:31] <stub> Admins have done their half of setting up edge.launchpad.net. It might be running next week depending on if any DB patches get landed before then. For anyone unclear, once a DB patch has been landed
[02:32] <stub> erm... didn't finish obviously ;)
[02:32] <stub> once a DB patch has landed, we cannot update edge.launchpad.net any more
[02:32] <SteveA> +1 on documenting the soyuz branch on LaunchpadProductionStatus
[02:32] <stub> because the code will expect a more recent database patch level than exists on the production database
[02:33] <stub> So the tricky part about edge.launchpad.net will be coordinating landing of branches containing database patches to minimize the periods when edge.launchpad.net cannot be updated.
[02:33] <stub> (done)
[02:33] <kiko> stub, SteveA: it would be nice if we invent some special processette to deal with db patches.
[02:33] <kiko> with patches that include db changes I meant.
[02:34] <salgado> stub, what about changes in lp/dbschema.py? don't they affect edge.launchpad.net too?
[02:34] <ddaa> sounds tricky since DB patches can be the sort of thing one want landed ASAP because they are often enablers for other developments
[02:34] <stub> cprov, malcc: Can one of you add a section to that page and keep it up to date when patches are made to production soyuz? I expect this will need to continue due to edgy release, so we should cope.
[02:34] <stub> ddaa: Indeed.
[02:34] <salgado> I mean, changes in lp/dbschema.py that don't require a DB patch or update script
[02:34] <malcc> stub: Yes, will do
[02:34] <cprov> stub: sure.
[02:35] <ddaa> stub: I heard the postgres could handle multiple schema with versioning, is that crazy, or could that help deal with that problem?
[02:35] <stub> salgado: Changes to dbschema.py that would break things will also need a database patch to perform the data migration.
[02:35] <salgado> I guess not... if they don't require not even an update script, these changes shouldn't be a problem
[02:35] <stub> salgado: Although production code might break if values are added to the database that the production code doesn't expect.
[02:35] <flacoste> salgado: they will, a new enum value unknown to the code in production will break validation and display
[02:36] <stub> salgado: So we need to be aware of the two production branches being run. Perhaps edge.launchpad.net will turn out to be a bad idea and we need to drop it, but I think it is worth giving a go.
[02:36] <SteveA> flacoste: true, but, they will break production only where edge.launchpad.net was used to set those values
[02:37] <SteveA> and production can be unbroken by using edge too
[02:37] <SteveA> so I don't see that as a big problem
[02:37] <stub> ddaa: re: multiple schemas, I'm not sure what you mean but I don't think that there are features of PostgreSQL that will make this less fragile (only more so).
[02:37] <ddaa> stub: okay, I was referring to some over-beer discussion I had in the past, nothing very specific
[02:37] <SteveA> over-beered perhaps
[02:38] <stub> Any other queries or comments?
[02:38] <kiko> SteveA, I didn't understand what you meant.
[02:39] <kiko> it's possible that production can't be unbroken by edge, fwiw
[02:39] <kiko> so I think dbschema updates should also block update.
[02:39] <kiko> they are fairly rare though.
[02:39] <SteveA> I'm unconcerned
[02:39] <SteveA> because they will break one thing in production
[02:39] <kiko> and we will get oopses
[02:39] <SteveA> not a whole feature in production
[02:39] <kiko> and I will be unhappy
[02:39] <SteveA> and we can deal with that
[02:40] <flacoste> SteveA: imagine adding a new importance
[02:40] <stub> It is an issue, but I suspect it will not happen in practice.
[02:40] <SteveA> I agree with stub
[02:40] <flacoste> SteveA: it could break most bugs display
[02:40] <kiko> I would rather not update if dbschema items were added.
[02:40] <salgado> how often do we simply add new items to dbschema values?
[02:40] <stub> So I don't think we need to worry about it unless it bites us (at which point we can escape by updating production to HEAD in the worst case)
[02:40] <kiko> I think it's a small thing for the safety it gives
[02:41] <stub> And reviewers provide a safety net if people don't think and arbitrarily change dbschema.py values
[02:41] <SteveA> you *could* load dbschema.py into the database as a source of constraint checking
[02:41] <stub> Anyway... we are running behind, and edge.launchpad.net doesn't exist yet.
[02:41] <SteveA> that would prevent edge changing stuff that will not work in production
[02:42] <stub>  * Launchpad 1.0 status reports
[02:42] <bradb> Malone 1.0
[02:42] <bradb> [02:42] <bradb> series-and-distrorelease-mgmt: Lives on staging these days; testers welcome. Blocked on decision about ConjoinedBugTasks. Open issue about having different release management permission "modes" for first rollout.
[02:42] <bradb> keeping-bugs-concise: No news.
[02:42] <bradb> guided-filebug-form: No news. bradb will be working on it again over the next week.
[02:42] <bradb> malone-essential-docs: No news.
[02:42] <bradb> simple-bug-keywords: No news.
[02:42] <bradb> Other: BjornT to clarify some spec statuses with kiko (i.e. if they can be considered "implemented", etc.)
[02:42] <ddaa> importd-bzr-native: DB schema cleanup through review, currently discussing how to sever indirect pybaz dependencies through hct, so we could wipe pybaz out of the dists tree.
[02:42] <ddaa> supermirror-smart-server: basic bzr functionality appears merged, launchpad integration up next, spiv reports it looks on track.
[02:42] <ddaa> bzr-roundrtrip-svn (postponed): waiting for mpool feedback on bzr ML discussion.
[02:42] <salgado> Question Tracker 1.0
[02:42] <cprov> = Soyuz-1.0 Report =
[02:42] <cprov>  * PPA: blocked on ArchiveRework (still).
[02:42] <cprov>  * Archive Rework: Moving, but slowly; this week has mostly been
[02:42] <cprov>    checking things after the deployment and little issues, malcc
[02:42] <cprov>  * Code quality: usual improvements motivated by code review.
[02:42] <cprov>  * SoyuzTestSystem: DONE ! redesigned parts are in production, ready
[02:42] <salgado> ---------------------------------
[02:42] <salgado> - SupportTrackerWorklow: API is completed. Karma integration is completed. UI is completed. Notifications integration is nearly completed.  Incoming email integration and expiration cronscript are pending. Should be up for review next week.
[02:42] <salgado> - SupportTrackerViews: Waiting completion of SupportTrackerWorkflow.
[02:42] <salgado> - SupportTrackerHelp: Waiting completion of SupportTrackerWorkflow.
[02:42] <cprov>    to edgy release.
[02:42] <salgado> - LocalizedSupportRequests: Started
[02:42] <cprov>  * NoMoreAptFtpArchive: nascentupload modified to populate new SPRs
[02:42] <salgado> Random Things 1.0
[02:42] <cprov>    properly and prototype script to populate old records
[02:42] <salgado> -------------------------------
[02:42] <cprov>  * General Fixing: slow progress
[02:42] <salgado> - PersonCreationRationale is reviewed and should be in rocketfuel today.
[02:42] <cprov>    * Fix released: 60440, 59291, 59280, 30264, 31609 (and several
[02:42] <salgado> - DirectPersonRegistration has a tricky issue blocking its implementation, so it needs discussion.
[02:42] <cprov>      other, lost the track)
[02:42] <cprov>    * Fix committed: 31392
[02:42] <cprov>    * In Review : 62545, 62447, 58835 and 58888
[02:42] <danilos> Rosetta 1.0 weekly report:
[02:42] <danilos> - opening edgy for translation: DONE
[02:42] <danilos> - firefox import/export: slow progress, TranslationImport spec'ed, needs preimplementation call
[02:42] <danilos> - oo import/export: blocked on firefox (TranslationImport stuff)
[02:42] <danilos> - translation review: blocked on kiko's restructuring work
[02:42] <danilos> - essential docs: no progress this week
[02:42] <danilos> - search: not started, pre-draft stage
[02:42] <danilos> - checks not to upload wrong language PO file using "too many changes" check: not started
[02:43] <danilos> - ui fixes: mpt on those
[02:43] <danilos> - outstanding issues: none
[02:43] <stub> I've forgotten the date 1.0 is supposed to be done :-(
[02:44] <danilos> early november, probably best to have everything ready by end of october, no?
[02:44] <kiko> everything in RF in two weeks time
[02:44] <kiko> apply for exceptions
[02:44] <carlos> kiko: two weeks???
[02:44] <stub> Any comments on the 1.0 reports?
[02:44] <malcc> I've never quite understood exactly what the 1.0 means in this context
[02:44] <danilos> kiko, now that's aggressive timing
[02:45] <ddaa> it was october 8th last I heard of it...
[02:45] <stub> carlos: Sounds like an exception application is needed
[02:45] <kiko> we're actually giving extra time
[02:45] <carlos> stub: well, it depends on how blocking things go....
[02:45] <kiko> but if you think you will be late you should apply for an exception this week
[02:45] <stub> Sysadmin requests!
[02:45] <mpt> RT #16869, which I submitted yesterday, about getting access to traffic logs for launchpad.net
[02:45] <kiko> and not in two weeks time.
[02:46] <jordi> danilos: whenever you are ready to discuss essential docs, just ping/mail
[02:46] <stub> 5
[02:46] <stub> 4
[02:46] <danilos> ok, carlos, some work for us then
[02:46] <stub> 3
[02:46] <stub> 2
[02:46] <stub> 1
[02:46] <danilos> jordi: sure, will do
[02:46] <SteveA> mpt: that doesn't need an RT ticket!
[02:46] <carlos> kiko: TranslationReviews should be in time if you finish the restructuring right now!!! :-D
[02:46] <mpt> SteveA, I talked to spiv and jamesh, and they said it does.
[02:46] <stub> SteveA: He means features.launchpad.net
[02:46] <carlos> danilos: yep
[02:46] <stub> (?)
[02:46] <jamesh> SteveA: I don't think we've got access to the apache logs
[02:47] <kiko> carlos, as I said, it's up for review.
[02:47] <SteveA> we have access to the apache logs
[02:47] <kiko> only 7 tests failed though!
[02:47] <jamesh> where?
[02:47] <stub> gangotri
[02:47] <mpt> stub, no, that's a separate RT ticket I didn't mention because I don't need it :-)
[02:47] <carlos> kiko: I saw test failing, but not that it's up to review
[02:47] <stub> ok - ignore me
[02:47] <carlos> kiko: I think that I will merge your branch then so I can resume my work
[02:48] <stub>  * Keep, Bag, Change
[02:48] <kiko> jamesh, btw, could you review that branch? it has some abstractions you may have a good eye for
[02:48] <stub> 5
[02:48] <stub> 4
[02:48] <SteveA> jamesh: gangotri:/var/log/apache2
[02:48] <stub> 3
[02:48] <stub> 2
[02:48] <bradb> Bag: meetings that go over 45 mins!
[02:48] <stub> 2.5
[02:48] <stub> 2.75
[02:48] <stub> 1
[02:48] <jamesh> kiko: the rosetta-view-refactoring one?
[02:48] <carlos> hmmm
[02:48] <stub>  * Three sentences
[02:48] <malcc> DONE: Soyuz deployment caught up, and still working! Some ArchiveRework.
[02:48] <malcc> TODO: Final tidying after Soyuz deployment, more ArchiveRework.
[02:48] <malcc> BLOCKED: No
[02:48] <ddaa> DONE: some remove-gnuarch work, started rewriting svn_oo.ChangesIterator (for python import)
[02:48] <ddaa> TODO: importd rollout, progress on pybaz eradication, implement new ChangesIterator
[02:48] <ddaa> BLOCKED: preimpl call on ChangesIterator (I might just do w/o one)
[02:48] <danilos> stub: that's some nice countdown ;)
[02:48] <jamesh> SteveA: I don't have access to that (mpt probably doesn't either
[02:48] <carlos> stub: shouldn't it be 2.25? ;-)
[02:48] <bradb> DONE: Duplicate bug handling changes up for review. Some refactoring in release management, to use LaunchpadFormView.
[02:48] <bradb> TODO: Land dupe handling changes. Reach a decision on ConjoinedBugTasks.
[02:48] <bradb> BLOCKED: Reach a decision on ConjoinedBugTasks. (kiko/mark)
[02:48] <kiko> jamesh, yes.
[02:48] <jordi> DONE: kde vs. rosetta discussion, email
[02:48] <salgado> DONE: Implemented the foundations of localized-support-requests, got person-creation-rationale through review, code review and other random things.
[02:48] <salgado> TODO: More localized-support-requests work, some mirror-management work, code review and other random things.
[02:48] <salgado> BLOCKED: No
[02:48] <matsubara> DONE: found the cause of the +export bug, wrote test for it. fetched the fix from upstream and nagged kiko to apply it to our SQLObject tree. Oops report analysi, triage, committed some trivialities. TODO: finish fix for #62423, 33663 and the project +review page to not crash, and more of the same.
[02:48] <matsubara> BLOCKED: no
[02:48] <BjornT> DONE: code reviews. upstream forwarding workflow, allowing URLs to be entered, removed the need for an extra click to add a bug watch.
[02:48] <cprov> DONE: soyuz rollout, soyuz bug fixes, NoMoreAptFtpArchive good progress
[02:48] <flacoste> DONE: implemented support tracker workflow ui, updated notifications for workflow changes
[02:48] <cprov> TODO: bugs blocking edgy+1, test new version of A-F in mawson
[02:48] <cprov> BLOCKED: no
[02:48] <danilos> DONE: TranslationImport drafting, bug 2181, partial bug 2718, plural forms for several languages
[02:48] <danilos> TODO: implement TranslationImport, TranslationExport, bug fixing, rosetta search
[02:48] <danilos> BLOCKED: no
[02:48] <flacoste> TODO: finish support tracker workflow and get it through review
[02:48] <Ubugtu> Malone bug 2181 in rosetta "Rosetta automated e-mail should come from @launchpad.net" [Medium,In progress]  http://launchpad.net/bugs/2181
[02:48] <Ubugtu> Malone bug 2718 in rosetta "/products/gnomebaker/+translations has a legend but no chart" [Medium,In progress]  http://launchpad.net/bugs/2718
[02:48] <BjornT> TODO: code reviews. attach files via email. make it easier to register bug trackers.
[02:48] <flacoste> BLOCKED: no
[02:48] <carlos> DONE: TranslationReview, Translation view restructuring, bug ,, #58504 and #46559, launchpad.net/rosetta/ navigation menu fixes, dapper translations hole recovery, fixed [|k|ed] ubuntu-docs templates for Edgy, OO.org translation exports for Edgy
[02:48] <mpt> DONE: bug fixes, specs
[02:48] <mpt> TODO: page designs(!), talk with ddaa, StructuralObjectPresentation
[02:48] <mpt> BLOCKED: not really, but lag with Usman is a concern
[02:48] <carlos> TODO: TranslationReview, finish #44214, reupload Dapper templates polluted by backports uploads
[02:48] <carlos> BLOCKED: On Kiko finishing translation views restructuring
[02:48] <BjornT> BLOCKED: no
[02:48] <kiko> DONE: refactor translation views. NOTHING else.
[02:48] <jordi> TODO: discuss KDE with danilo & send; some queue
[02:49] <jamesh> DONE: code reviews, bug export, "bzr branch https://launchpad.net/product/foo" hack, bzr-0.11 compatibility, untangling $series/+source form
[02:49] <jordi> BLOCKED: no
[02:49] <jamesh> TODO: code reviews, finish off untangling +source form, get product-release-finder ready for production, get url utils branch ready for review
[02:49] <jamesh> BLOCKED: no
[02:49] <stub> DONE: OOPS cleaner
[02:49] <stub> TODO: edge.launchpad.net
[02:49] <stub> BLOCKED: Nope
[02:49] <kiko> TODO: Launchpad report. deal with reviews and land my 4 pending branches. 
[02:49] <spiv> DONE: bzr smart server, reviews, authserver performance diagnosis
[02:49] <spiv> TODO: reviews, bzr smart server, smart server/supermirror integration
[02:49] <spiv> BLOCKED: no
[02:49] <SteveA> DONE: management, ui work
[02:49] <SteveA> TODO: management, ui work
[02:49] <SteveA> BLOCKED: no
[02:49] <kiko> BLOCKED: review on that branch, but I put it up yesterday 
[02:50] <stub> Ooh... blocked on conflicts between existing product names (malone, rosetta, bazaar) and pillar-name shortened urls.
[02:50] <SteveA> kiko: please prepare your three sentences in a text editor, then paste them into channel all at once
[02:50] <stub> Any blockages there that need to be discussed in the meeting?
[02:50] <mpt> stub, I was waiting for that to happen
[02:50] <stub> 8
[02:50] <stub> 7
[02:50] <stub> 6
[02:50] <stub> 5
[02:50] <stub> 4
[02:50] <stub> 3
[02:50] <SteveA> kiko is blocking brad
[02:50] <jamesh> stub: name them +malone, +rosetta and +bazaar?
[02:50] <SteveA> and also the rosetta team
[02:50] <kiko> stub, let's move to +malone +rosetta +bazaar
[02:51] <mpt> kiko, or bugs.launchpad.net etc
[02:51] <SteveA> kiko: make sure they know the plan for unblocking them
[02:51] <carlos> steveA: well, more than kiko, the reviewer for kiko's branch
[02:51] <bradb> My blockage is simmering on low heat. Not much else to say during this meeting.
[02:51] <kiko> SteveA, I don't know what to do about CJBT.
[02:51] <SteveA> kiko: that's a call then.
[02:51] <kiko> with god?
[02:51] <stub> ok. Meeting over. blockage discussion can continue ;)
[02:51] <bradb> heh
[02:52] <ddaa> mpt: ping!
[02:52] <SteveA> jamesh: I see that you and mpt don't have access to gangotri.  But that still doesn't make it an RT request.
[02:52] <stub> SteveA: Any objections to me changing urls to +malone etc. rather than waiting on bugs.launchpad.net to arrive?
[02:52] <mpt> ddaa, pong
[02:52] <SteveA> stub: can't we just use the blacklist instead?
[02:52] <ddaa> mpt: let's set up a time for the call now
[02:52] <kiko> SteveA, and rename our products?!
[02:52] <malcc> Can someone explain what launchpad 1.0 is, or point me to the docs, so I can work out whether or not Soyuz needs to apply for an exception?
[02:52] <carlos> SteveA, kiko: When will we know who should attend Ubuntu conference next November?
[02:52] <stub> SteveA: Only if we want to rename bazaar to something new
[02:52] <ddaa> mpt: it looks like the bazaar meeting will be on tuesday next week, so what about monday 0900 UTC?
[02:53] <SteveA> mpt: which RT issues have you filed about getting logs?  And, considering that stub or I can get you the logs, which RT issues do you still need?
[02:53] <kiko> malcc, soyuz has falled off 1.0.
[02:53] <stub> (we can just drop the malone and similar products, which I was going to have as a meeting agenda item but forgot to add it)
[02:53] <danilos> off to lunch now; BjornT, will you be available tommorow morning for preimplemenation call? re https://launchpad.canonical.com/ITranslationImporter (but I still haven't updated this with latest spec, will do that after I get hold of my other computer)
[02:53] <carlos> malcc: https://features.launchpad.net/products/soyuz/1.0/+specs
[02:53] <kiko> stub, well, is there an ETA for bugs.launchpad.net?
[02:53] <malcc> kiko: Ok, cool
[02:53] <danilos> stub, anyone: please update the channel topic for the next meeting ;)
[02:53] <SteveA> stub: so, these are for the application homepages?  +code, +bugs, +translations, +features
[02:53] <stub> malcc: There are a number of features and bugs flagged 1.0. This is the stuff needed to declare Launchpad 1.0.
[02:53] <kiko> fallen off, malcc, sorry. I'm kinda bonkey right now
[02:54] <matsubara> SteveA: at devpad:/srv/launchpad.net-logs/production/gangotri/ there's a launchpad-access1.log. Isn't that what they want?
[02:54] <SteveA> matsubara: no
[02:54] <stub> SteveA: Yes
[02:54] <kiko> matsubara, that's not apache, it's simulated apache generated by the appserver.
[02:54] <jamesh> SteveA: okay.  I didn't know that we had access to the data, so suggested asking the admins.
[02:54] <dani[lunch] o> stub: thanks ;)
[02:54] <malcc> Ok, yes, well it sounds like everyone already knows this then, but let's just say for the record that the soyuz 1.0 specs won't be in place in two weeks. Maybe two months, with a following wind and some luck
[02:54] <kiko> matsubara, it lacks for instance real client IP addresses.
[02:54] <BjornT> dani[lunch] o: sure, i should be able to do a call tomorrow
[02:54] <SteveA> stub: then, please rename them to +code, +bugs, +translations, +features, unless these names conflict with existing names.
[02:54] <stub> SteveA: Current /bazaar would be moved to /+bazaar. /bazaar would become the bazaar product home page. 
[02:54] <SteveA> move it to +code, I'd say
[02:54] <kiko> SteveA, +code or +branches?
[02:55] <SteveA>  +code
[02:55] <kiko> I think it was +code
[02:55] <mpt> SteveA, I submitted one about webstats.launchpad.net not showing features.launchpad.net (which is now low priority, I don't need it), and #16869 on getting the raw logs
[02:55] <stub> SteveA: ok.
[02:55] <kiko> okay
[02:55] <cprov> malcc: so, we can discuss it with managers if necessary 
[02:55] <dani[lunch] o> BjornT: ok, thanks, I'll ping you when I put the spec up on the wiki so you can take a look before the call if you wish
[02:55] <SteveA> mpt: ok.  please cancel 16869
[02:55] <mpt> ok
[02:56] <cprov> malcc: AFAICS, just PPA won't be reached, isn't it ?
[02:56] <SteveA> mpt: what period of time of logs for launchpad.net and features.launchpad.net do you want?
[02:56] <kiko> cprov, there was not much else for soyuz 1.0..
[02:56] <malcc> cprov: Yes, that seems likely
[02:56] <BjornT> dani[lunch] o: cool. i definetely want to read through the spec before the call.
[02:57] <kiko> jamesh, was that a yes? :)
[02:57] <SteveA> mpt: the log files appear to be rotated weekly
[02:57] <mpt> SteveA, you suggested two months
[02:57] <jordi> dani[lunch] o: I expect to be around at 5?
[02:57] <jamesh> kiko: about the branch?  Okay.
[02:57] <cprov> kiko: we bring cron.daily back to reasonable cycles, b-f-n  and ArchiveRework ... they are important.
[02:57] <sabdfl> cprov: ping
[02:57] <kiko> jamesh, I'm very happy to hear that
[02:58] <sabdfl> cprov: how do i see the NEW or UNAPPROVED queue?
[02:58] <cprov> sabdfl: pong
[02:58] <kiko> cprov, you're right, I guess
[02:58] <cprov> sabdfl: you need admin or archive-admin permission
[02:58] <sabdfl> as a launchpad-admin, do I have that?
[02:59] <SteveA> mpt: let's start with less
[03:00] <sabdfl> +code, folks, and code.launchpad.net
[03:00] <cprov> sabdfl: the right term is upload_admin, sorry. I think you are lp-admin, let me check 
[03:00] <sabdfl> cprov: i see no links from the distro home page
[03:02] <cprov> sabdfl: distros/ubuntu/edgy has a +queue (View Uploads)
[03:03] <sabdfl> got it, thanks!
[03:04] <cprov> sabdfl: https://launchpad.net/people/ubuntu-archive is the upload_admin celebrity
[03:04] <cprov> sabdfl: np
[03:04] <SteveA> mpt: chinstrap:/home/stevea/logs/
[03:05] <kiko> cprov, sabdfl: I'd like us to move all the role-related fields to a single /distros/ubuntu/+roles page
[03:05] <kiko> which had text that made absolutely clear what the roles were used for
[03:05] <kiko> are you +1/-1 on this idea?
[03:06] <mpt> thanks SteveA 
[03:06] <cprov> kiko: +1, I guess ... to make roles clearer is nice, not sure if we can organize this properly inthe current enviromment.
[03:07] <kiko> the current mess of multiple pages is reported to be "very distressing"
[03:07] <salgado> spiv, around?
[03:09] <cprov> kiko: yes, it is. Very unclear to find out "who is who" within the distro context or "why i can or can't do something"  
[03:19] <ddaa> jamesh: just remembered
[03:20] <ddaa> jamesh: I merged my fix for $series/+source yesterday
[03:20] <ddaa> jamesh: so you should probably merge with rocketfuel to resolve the conflicts
[03:24] <salgado> do we have any service that could create launchpad accounts using the authserver?
[03:24] <kiko> salgado, I'm not very sure. what uses authserver apart from the wiki? forums?
[03:25] <salgado> AFAIK, only the wiki
[03:35] <flacoste> kiko, salgado: ping
[03:36] <kiko-afk> flacoste, yessss?
[03:36] <flacoste> i would like to apply for an exception for the 1.0 deadline
[03:36] <flacoste> kiko-afk: ^^^
[03:36] <kiko-afk> flacoste, denied. next question?
[03:36] <kiko-afk> more seriously, write an email with the request
[03:37] <flacoste> kiko-afk: ok
[03:49] <flacoste> salgado: ping
[03:49] <salgado> flacoste, pong
[03:49] <flacoste> salgado: how is it going with the localization of support requests?
[03:49] <flacoste> salgado: i'm afraid we might conflict on that one
[03:50] <flacoste> salgado: since my support-tracker-workflow patch touches almost everything in the support tracker subsystem
[03:51] <flacoste> salgado: only things i don't touch is the ticket creation, so we might escapce conflict
[03:51] <salgado> flacoste, I've done only the basic foundations for it. that is, added the necessary columns and turned rosetta/prefs into a generic page where you choose your language preferences
[03:52] <salgado> flacoste, when do you expect to finish working on your support-tracker-workflow branch?
[03:52] <flacoste> salgado: I expect to put it up for review monday or tuesday at the latest
[03:54] <flacoste> salgado: can you push your branch daily on devpad? I could take a look at it and forewarn you of any conflicts
[03:54] <flacoste> salgado: mine is available as .../flacoste/launchpad/tt-workflow
[03:55] <salgado> flacoste, okay, so I'll try to check your changes periodically, and use them to plan my work
[03:55] <salgado> mine is also there, as localized-support-requests, and I push it at least once a day
[03:55] <flacoste> salgado: cool!
[03:55] <salgado> flacoste, thanks for the heads up. :)
[03:55] <flacoste> salgado: i'll take a look at it right now
[03:56] <flacoste> salgado: np!
[03:56] <flacoste> salgado: we'll conflict on sampledata for sure, but that's not a big problem
[03:57] <salgado> flacoste, yeah, I can revert these sampledata changes without problem and then delay any other changes until you've landed your branch
[03:58] <flacoste> salgado: my branch is huge (now 6050 lines and it will grow), so i expect the review process to be a little long
[03:58] <salgado> wow. 6k lines
[03:58] <flacoste> salgado: you might get there first :-)
[03:59] <flacoste> salgado: mostly documentation and tests though, but still
[03:59] <salgado> indeed, still pretty big
[04:01] <flacoste> salgado: apart from the sampledata, up to now, we don't really have significant conflicts
[04:02] <salgado> cool
[04:02] <flacoste> salgado: we might have some related to the indendation changes you did to some ticket attributes, but that's also trivial
[04:02] <salgado> I'll try merging your branch into mine every once in a while to see how things go
[04:02] <flacoste> salgado: ok
[04:03] <flacoste> salgado: if you planned to add the language attribute to the ticket edit view, you better do it after merging my branch, i refactored that one
[04:04] <flacoste> salgado: problem with my branch is that support-tracker-emailinterface.txt fails (that's where i am at now)
[04:04] <flacoste> salgado: but that should be fixed by tomorrow night
[04:05] <kiko-afk> carlos, btw, I got rid of some dead code in the pofileview that I can only imagine existed to restrict display of translations with errors.
[04:05] <kiko-afk> carlos, I have a separate patch which implements that correctly but I need tests for it
[04:05] <salgado> flacoste, hmmm. okay.  I'll delay the changes on the edit view, then.
[04:07] <Spads> http://www.launchpad.com/people/nick-zork  <-- known?
[04:07] <carlos> kiko-afk: ok, if You want that I take a look to that patch...
[04:08] <Spads> oh eh
[04:08] <Spads> sorry, someone sent me a bogus URL
[04:09] <jamesh> ddaa: yeah.  I fixed those conflicts
[04:09] <kiko-afk> carlos, do you think that feature is worth it?
[04:09] <kiko-afk> carlos, it's pretty simple to implement -- the patch is tiny
[04:09] <jamesh> ddaa: I also finished off the bzr-0.11 compatibility fixes
[04:09] <ddaa> jamesh: I'll wait for your work to land before stepping on your toes further
[04:09] <kiko-afk> it depends on my patch though
[04:10] <kiko-afk> carlos, it could be post-1.0 though if you prefer
[04:10] <carlos> kiko-afk: well, I don't know exactly which part of the code you talk about, I'm just offering me to check it, nothing else ;-)
[04:10] <carlos> sure
[04:10] <ddaa> jamesh: I received the email, I plan to have a look after I have done the importd rollout and import herding
[04:15] <kiko-afk> carlos, for now let's leave it, I can come back to it later.
[04:15] <jamesh> ddaa: the changes weren't too big, which is good.
[04:16] <carlos> kiko-afk: ok
[04:16] <ddaa> *nod* I did not expect them to be big, but I would have had to get familiar with the supermirror code, and learn how to do proper bzrlib testing (ScratchBranch and friends).
[04:16] <ddaa> since bzrlib is supposed to be mostly stable now
[04:17] <jamesh> ScratchBranch doesn't exist in bzrlib
[04:18] <jamesh> there was an unused ScratchDir import in the supermirrorsftp acceptance tests which was causing problems too
[04:18] <ddaa> okay, that was sort of an easy fix then :)
[04:18] <malcc> Is there any launchpad news on who's needed at UDS yet?
[04:19] <kiko-afk> malcc, not yet, but I'm hoping nobody
[04:19] <kiko-afk> 1.0 is too short for love
[04:19] <ddaa> jamesh: since I have trouble getting hang of lifeless, maybe you would like to do preimpl about that cscvs change I designed yesterday
[04:19] <jamesh> ddaa: okay
[04:20] <ddaa> I plan to rewrite the svn_oo.ChangesIterator not to be utterly stupid, but it turns out to be quite complicated to do correctly
[04:20] <malcc> kiko-afk: Cool, thanks
[04:20] <ddaa> so, nevermind if you are tired and sleepy, I do not think it will work out
[04:20] <malcc> kiko-afk: Let us know when it's final obviously
[04:21] <jamesh> ddaa: should we try the company voip?
[04:22] <ddaa> jamesh: it works for me, what you feel most comfortable with
[04:22] <jamesh> ddaa: okay.  Should I call you?
[04:23] <ddaa> give me a couple of mins
[04:26] <ddaa> jamesh: I'm online
[04:30] <ddaa> jamesh: my skype id is david.allouche
[04:32] <jamesh> ddaa: didn't seem to connect.  I'll try again
[05:21] <kiko-afk> carlos, ping?
[05:22] <carlos> kiko-afk: pong
[05:27] <kiko-afk> carlos, can you help me with a question I have?
[05:27] <carlos> sure
[05:27] <carlos> tell me
[05:29] <kiko-afk> can you look with me at browser/pomsgset.py?
[05:29] <carlos> your version or rocketfuel one?
[05:29] <kiko-afk> carlos, the code which is currently in our tree, not my branch?
[05:30] <carlos> ok, rocketfuel
[05:30] <carlos> I have it open
[05:30] <carlos> kiko-afk: tell me
[05:30] <kiko-afk> carlos, so the code there does uniquing of the suggestions, correct?
[05:30] <kiko-afk> carlos, and it does it based on: posubmission.potranslation.translation
[05:30] <kiko-afk> carlos, is my understanding correct?
[05:30] <carlos> yeah, it should, but I found some bugs on that....
[05:31] <kiko-afk> carlos, oh?
[05:31] <carlos> I didn't debugged it yet, but I have seen our production system showing duplicates
[05:31] <kiko-afk> hmmm.
[05:31] <kiko-afk> carlos, so my code is much more simplistic, but I think it's wrong.
[05:31] <carlos> but yeah, what you described is what is supposed to be the right thing to do
[05:31] <kiko-afk>         active = set([self.translations[index] ] )
[05:31] <kiko-afk>         wiki = set(self.context.getWikiSubmissions(index))
[05:31] <kiko-afk>         current = set(self.context.getCurrentSubmissions(index))
[05:31] <kiko-afk>         suggested = set(self.context.getSuggestedSubmissions(index))
[05:31] <kiko-afk>         wiki = wiki - current - suggested - active
[05:31] <carlos> kiko-afk: I guess there aren't enough test for this
[05:31] <kiko-afk>         wiki = self._buildSubmissions("Suggested elsewhere", wiki)
[05:31] <carlos> so don't relay on them
[05:31] <kiko-afk> carlos, this is my code.
[05:32] <kiko-afk> it doesn't even look in potranslation.translation
[05:32] <kiko-afk> at all
[05:32] <kiko-afk> it's wrong, right?
[05:32] <kiko-afk> it just uniques the POSubmissions
[05:32] <kiko-afk> which I thought was correct but now I realize
[05:32] <carlos> no, it's not enough
[05:32] <kiko-afk> that two posubmissions can have the same potranslation.translation
[05:32] <kiko-afk> right?
[05:33] <carlos> yeah, but for different POMsgSet
[05:33] <kiko-afk> and getWikiSubmissions would return both, correct?
[05:33] <carlos> right
[05:33] <kiko-afk> thanks. I'll fix my code.
[05:33] <kiko-afk> I SUCK
[05:33] <kiko-afk> argh
[05:35] <carlos> kiko-afk: well, context.getWikiSubmissions should remove the ones that currently are set as active
[05:36] <kiko-afk> ok.
[05:39] <carlos> kiko-afk: please, could you add a couple of tests for this duplicate removal feature ?
[05:39] <carlos> wow 5 files with conflicts....
[05:40] <SteveA> kiko-afk-longarms: I just mailed you about that interview.
[05:41] <kiko-afk> yeah.
[05:51] <carlos> kiko-afk: so you fall in class inheritance.... ;-)
[06:03] <carlos_> kiko-afk: "kiko, 2006-0-27"
[06:03] <salgado> carlos_, ping
[06:03] <carlos_> kiko-afk: nice month ;-)
[06:03] <carlos> salgado: pong
[06:04] <salgado> carlos, why is the language named 'English' not visible?
[06:04] <salgado> I mean, why does it have visible = false on production
[06:04] <carlos> salgado: because translations for 'en' makes no sense, that's the original language anyway
[06:05] <carlos> salgado: do you need it outside Rosetta context?
[06:05] <kiko-afk> carlos, faster than the speed of dark
[06:05] <salgado> carlos, yes
[06:05] <carlos> salgado:  in Rosetta, people should use en_AU, en_GB, en_US but never 'en'
[06:05] <carlos> salgado: how are you going to use it?
[06:07] <salgado> carlos, we're going to allow people to make support requests in multiple languages
[06:07] <carlos> we use the .visible flag to show it in our UI when no translation for 'en' exists, if there is any translation already, because someone used a hand made URL, or an admin approved it, we show it in our UI
[06:08] <carlos> salgado: aren't you using Englis (en) as the base language for all support requests?
[06:08] <carlos> I mean, by default
[06:08] <salgado> carlos, and I thought I could use Person.languages to track the preferred languages of support contacts and users, to, by default, show only requests on their preferred languages
[06:09] <carlos> I see
[06:09] <carlos> in which case, you need 'en' enabled
[06:09] <carlos> hmm
[06:09] <carlos> what about 'es_ES' vs 'es_MX' vs 'es'?
[06:09] <carlos> do you want to allow any of them?
[06:09] <carlos> or just 'es'?
[06:10] <salgado> just es and just en, I guess
[06:10] <carlos> ok
[06:10] <carlos> we could improve the system so you can reuse it
[06:10] <salgado> how can we do that?
[06:11] <carlos> I guess is not a big deal 'hardcoding' 'en' in Rosetta code to filter it by default, as it's a special case of the way application translation works
[06:11] <carlos> I mean, the corner case here is Rosetta
[06:12] <carlos> and it's just one language, so makes no sense to have two flags and two preferences for Rosetta and other parts of launchpad
[06:12] <salgado> yeah, but I'm afraid we'll need two separate preferences anyway
[06:12] <carlos> salgado: but that would mean too that rosetta/prefs should be moved to a more general preference to note that it's not just Rosetta which uses it
[06:12] <carlos> salgado: why?
[06:14] <carlos> salgado: I think Mark (I'm not completely sure whether Mark did the proposal) proposed sometime ago to have 'Reading preferences' and 'translation preferences'
[06:14] <carlos> if that's what you are thinking on
[06:14] <salgado> carlos, because I don't think it makes sense to allow people to make support requests in, let's say, 'en_CA'
[06:14] <salgado> I think what we have now is too fine grained for localized-support-requests
[06:15] <carlos> well, that's your special case....
[06:15] <carlos> I mean, it's just English the special case here
[06:15] <carlos> either for you or for us
[06:15] <carlos> salgado: pt_BR is a valid locale
[06:15] <carlos> or zh_CH, zh_TW instead of just zh
[06:16] <carlos> the only problematic languages for you that I can remember right now are the en_* ones
[06:16] <carlos> the others are exactly what you want/need
[06:17] <flacoste> carlos: well, fr_CA vs fr_FR, fr_BE is too fine grained and I guess the same is true of es_*
[06:17] <salgado> exactly, that's what I was thinking
[06:17] <carlos> flacoste: sure, but for support requests and for Rosetta, those have visible = False
[06:18] <carlos> so those aren't an issue here
[06:18] <flacoste> carlos: ok, iiuc, the only problem is that en.visible = False?
[06:18] <salgado> ahh, then I guess everything should be fine
[06:19] <carlos> one thing we try a lot when we add new languages is to prevent the activation of those languages and adding another field specific for user support will double the work to manage it
[06:19] <carlos> flacoste: that en.visible = False and en_XX = True
[06:19] <flacoste> right
[06:20] <carlos> my proposal is to set en.visible = True and fix Rosetta to handle that special case and handle en_XX as a special case in support requests
[06:20] <carlos> just to do the right thing
[06:20] <carlos> if we want something fast and easy, support request could handle too 'en' as an special case
[06:22] <salgado> yeah, sounds like a plan
[06:23] <carlos> salgado: I don't think we could do the Rosetta part in next two weeks, but after 1.0 (in two weeks) we could take a look on that
[06:24] <salgado> carlos, I'll summarize this and send it to launchpad@, just in case somebody wants to join the discussion
[06:24] <salgado> carlos, ok. I'll have to either workaround that or do it myself then, because this branch is targeted at 1.0
[06:24] <carlos> salgado: btw, I think that in this situation, the language preferences form should be moved under people/id/+prefered-languages or something like that
[06:25] <salgado> carlos, it's already there. :)
[06:25] <kiko-afk> carlos, what should take precedence: Used Elsewhere, or Suggestions?
[06:25] <salgado> (I mean, in this branch that I'm working on)
[06:25] <kiko-afk> carlos, i.e. if there is the same string in both, which should we present?
[06:25] <carlos> salgado: we are a bit behind with the schedule for 1.0 if we see that have enough time to do it I will tell you it
[06:26] <carlos> salgado: ok
[06:26] <salgado> carlos, cool. thanks a lot
[06:26] <carlos> kiko-afk: Suggestions
[06:26] <carlos> kiko-afk: Used Elsewhere is for entries in other templates
[06:26] <kiko-afk> okay.
[06:26] <carlos> kiko-afk: hmmm, in fact....
[06:27] <kiko-afk> carlos, can you take a look at: http://localhost/distros/ubuntu/hoary/+source/evolution/+pots/evolution-2.2/es/14/+translate
[06:27] <kiko-afk> and tell me 
[06:27] <kiko-afk> does that suggestion not duplicate what the active_text is?!
[06:27] <carlos> Used Elsewhere are for strings that are actually selected/approved in other places...
[06:27] <kiko-afk> errr, the used elsewhere I mean.
[06:28] <carlos> kiko-afk: forget what I told you in the first place, in the spirit of getting as much reused as possible, give preference to 'Used elsewhere' over Suggestions, and give more priority to Suggestions than Wiki ones
[06:28] <carlos> kiko-afk: I get a not found
[06:29] <carlos> sorry...
[06:29] <carlos> I need to turn on my local server... :-P
[06:31] <carlos> kiko-afk: yeah, that's the confirmation of the bug I told you about 
[06:33] <ddaa> jamesh: looked at your bzr-0.11 branches
[06:34] <ddaa> jamesh: it looks like the cscvs one is incompatible with bzr 0.9, and that it is a watershed patch like the launcphad one.
[06:34] <ddaa> But you already know that, I figure.
[06:34] <ddaa> It all looks good as far as I am concerned.
[06:38] <Tonio_> I was wondering if http://tonio.homelinux.org/tmp/capture13.png was a bug
[06:39] <Tonio_> sounds strange that launchpad doesn't find any untranslated strings as 84% only is translated so far...
[06:40] <ddaa> it might just be that the statistics are lying
[06:40] <ddaa> IIRC, they are expensive to generate, and are done in batch
[06:40] <ddaa> there might be a way to display a marker to make it clear when the stats are out of date though
[06:41] <ddaa> carlos: danilos: is that possible, and if yes, is there already a bug open about this?
[06:42] <carlos> let me check
[06:42] <carlos> Tonio_: check for the ones that 'Needs review'
[06:43] <carlos> ddaa: thanks for the ping
[06:43] <Tonio_> carlos: yes I've seen this, but should it appear as 100% translated with review needed ?
[06:43] <Tonio_> carlos: that's a bit confusing in my opinion
[06:44] <carlos> yeah, I guess, it's a side effect of a missing feature that splits 'fuzzy' from Needs review
[06:45] <carlos> we are abusing of 'Needs review' feature right now until fuzzy support is in place
[06:46] <Tonio_> carlos: okay thanks for this info :) I'll just have to wait then.
[06:46] <carlos> Tonio_: danilo and I want to fix it as soon as we finish some high priorities in Rosetta
[06:47] <Tonio_> carlos: great ;)
[06:47] <carlos> we hope to have it fixed before the end of the year, but it depends on how other tasks go (like search)
[06:54] <carlos> salgado: btw, about language selection
[06:55] <carlos> salgado: Rosetta uses other sources of information if the user didn't select any language in the language form
[06:55] <carlos> salgado: like the browser preferences or the geoip info
[06:56] <carlos> I think you could be interested on those too to offer answers in other languages
[06:57] <kiko-afk> matsubara, I liked your analysis. building communities by christian reis.
[06:58] <salgado> carlos, yeah, I'm going to use that too. :)
[06:58] <carlos> feel free to suggest a better API that fits you and Rosetta
[06:58] <SteveA> go kiko-afk 
[06:59] <SteveA> ddaa: ping
[07:01] <kiko-afk> carlos, for the record, "Suggestions" are translations that are fuzzy, right?
[07:01] <kiko-afk> carlos, and "wiki" are "non-editor translations"
[07:01] <kiko-afk> is that correct?
[07:02] <carlos> kiko-afk: no
[07:02] <carlos> Suggestions are 'non-editor translations' done in self.context
[07:02] <kiko-afk> ah.
[07:02] <kiko-afk> okay.
[07:02] <carlos> wiki are the same but comming from other contexts
[07:03] <kiko-afk> okay gotcha.
[07:03] <carlos> well, non editor translations + upstream ones (if different from the current translation)
[07:03] <carlos> kiko-afk: I want to note the ones that come from upstream vs the ones that are just suggestions from non-editors
[07:03] <carlos> but that will be another branch
[07:04] <carlos> kiko-afk: our system is not able to know whether a POSubmission is fuzzy or not, we store the information inside the POMsgSet object, and that sucks, but that's also another bug/fix
[07:05] <carlos> kiko-afk: https://features.launchpad.net/products/rosetta/+spec/rosetta-fuzzy-merge
[07:07] <kiko-afk> carlos, gotcha.
[07:07] <kiko-fud> carlos, I fixed the bug. the code is not beautiful but...
[07:07] <carlos> kiko-fud: well, we will improve that later ;-)
[07:08] <kiko-fud> carlos, https://devpad.canonical.com/~andrew/paste/fileskvfVy.html
[07:10] <carlos> kiko-fud: - Non-editor translations to this context (non_editor) <- non_editor + upstream when different from current string
[07:10] <kiko-fud> carlos, no, upstream is elsewhere. no?
[07:10] <kiko-fud> oh, upstream is special? 
[07:11] <kiko-fud> flacoste-lunch, midwife? you in trouble?!
[07:11] <carlos> upstream translation that we got for this context
[07:11] <flacoste-lunch> kiko-fud: that's one way of seeing it ;-)
[07:11] <kiko-fud> carlos, I'm out for lunch, but can you /privmsg me an explanation?
[07:12] <carlos> sure
[07:16] <carlos> kiko-fud: I don't see it as ugly as you said... perhaps a small comment to prune_dict method would make it more clear, but nothing more...
[07:18] <jordi> danilo's not here?
[07:19] <bradb> jordi: connectivity problems, according to his mail
[07:20] <jordi> oh
[07:25] <carlos> see you later!
[07:26] <jordi> carlos: laters
[07:34] <bradb> kiko-fud: remember this? https://devpad.canonical.com/~bradb/search_filter.png
[07:55] <kiko-fud> bradb, ah!
[07:56] <kiko-fud> bradb, would need to be smaller, more discrete
[07:57] <kiko-fud> discreet I mean
[07:57] <bradb> to each his own. anyway, i updated the bug report with the branch i put the patch in.
[08:01] <sabdfl> and possible below the current results
[08:01] <sabdfl> seems silly to push the results further down the page
[08:01] <sabdfl> alternatively, use space to the left of results
[08:01] <sabdfl> kiko, stevea, ping
[08:02] <kiko-fud> sabdfl, yes?
[08:03] <kiko> bradb, cool.
[08:03] <bradb> sabdfl: i think the filter would be invisible under the results, and somewhat invisible in the sidebar
[08:04] <bradb> it pushes the results a bit down the page, but tells the user exactly what they're being shown, so it's an ok tradeoff, IMHO
[08:04] <kiko> not sure if we are optimizing for visibility here..
[08:04] <kiko> anyway, we  can work it out from the patch
[08:04] <bradb> indeed. wasn't planning on discussing it more, tbh.
[08:06] <sabdfl> cool
[08:06] <sabdfl> kiko: we have an interesting candidate, who has another offer on the table, think you can squeeze in a call today?
[08:07] <kiko> sabdfl, I have this massive report to write up, and I'm in the middle of it
[08:07] <kiko> sabdfl, what timezone is it?
[08:08] <bradb> BjornT: ready for that call in a few mins? i'm just pondering an email from spiv beforehand, for discussion.
[08:19] <sabdfl> kiko: he's in the US, East Coast
[08:20] <BjornT> bradb: sure. i'll be ready in 5 minutes.
[08:20] <bradb> BjornT: ok
[08:21] <kiko> sabdfl, and it needs to be today or it can be tomorrow?
[08:21] <kiko> sabdfl, if possible I'd prefer the latter, once I've shipped this report to everybody who cares
[08:25] <sabdfl> kiko: can be a quick interview, this evening preferred if possible, otherwise i'll run with steve's view
[08:25] <sabdfl> we're not going to make an offer, but i want to give him a reasonable indication of interest
[08:25] <sabdfl> i mean not make an offer TODAY
[08:25] <kiko> gotcha
[08:25] <kiko> okay
[08:27] <BjornT> bradb: i'm online on skype now. call me when you are ready.
[08:43] <Kuhrscher> carlos: I just mailed you the requested tarball
[08:46] <Yannig> Hello everybody :)
[08:46] <Yannig> If someone has an idea about https://launchpad.net/distros/ubuntu/+source/gnome-keyring-manager/+bug/62832 :D
[08:46] <Ubugtu> Malone bug 62832 in gnome-keyring-manager "Difference between "show all" and "show untranslated"" [Undecided,Unconfirmed]  
[08:48] <carlos> Kuhrscher: cool, thanks
[08:48] <carlos> I guess I should upload it for Dapper and Edgy, right?
[08:48] <carlos> Yannig: let me see...
[08:49] <Kuhrscher> Would be nice :)
[08:49] <Kuhrscher> It's a svn snapshot of the translations of extragear-pim for all languages
[08:50] <Kuhrscher> It also contains some files for other apps of this module
[08:50] <carlos> ok
[08:50] <Kuhrscher> I hope this is not a problem
[08:55] <Kuhrscher> carlos: if you need something similar, feel free to contact me
[08:55] <carlos> I will need to split them by domains, but don't worry, it's easy
[08:55] <carlos> Kuhrscher: ok, thanks
[08:56] <Kuhrscher> carlos: Great
[08:56] <Kuhrscher> Ok, bye
[08:58] <carlos> Kuhrscher: bye
[09:10] <Ubugtu> New bug: #62832 in rosetta "Difference between "show all" and "show untranslated"" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62832
[09:15] <Yannig> Thanks, I saw it :)
[09:15] <carlos> Yannig: I see 96 messages in both
[09:17] <Yannig> After translating 3 strings, I can see 93 now
[09:17] <Yannig> Strange enough :$
[09:18] <carlos> :-?
[09:19] <carlos> ok, I'm able to reproduce the error
[09:19] <carlos> Yannig: thanks for the report
[09:19] <Yannig> You're welcome :)
[09:20] <carlos> see you later!
[09:23] <SteveA> salgado: ping
[09:23] <salgado> SteveA, pong
[09:42] <ddaa> Okay, importd rollout appears complete
[09:42] <ddaa> needed a couple of band-aid fixes though
[09:43] <ddaa> and than uncovered an interesting dependency
[09:43] <ddaa> our buildbot actually depends on launchpad!
[09:44] <ddaa> I heard someone say "that's broken dude!"
[09:58] <kiko> that's broken
[09:58] <kiko> what does it depend on?
[10:25] <j-a-meinel> ddaa: howdy
[10:25] <ddaa> j-a-meinel: I am not sure that the wiki is very relevant
[10:25] <j-a-meinel> So the lines: We already have an sftp server for the supermirror based on the Twisted Conch server, so we will extend that to run the smart server
[10:25] <j-a-meinel> is directly contradicted by the next paragraph
[10:26] <ddaa> j-a-meinel: nobody cares about that spec now
[10:26] <j-a-meinel> so what do you want me to review?
[10:26] <j-a-meinel> just the summary?
[10:26] <ddaa> the whiteboard on the spec page on launchpad
[10:26] <j-a-meinel> ahh, okay.
[10:27] <j-a-meinel> sounds a little like you are mixing bzr-0.11 with stuff that will be in bzr-0.12 (the bzr+http stuff). but the status otherwise looks fine.
[10:31] <ddaa> okay, that's worth clarifying
[10:31] <ddaa> j-a-meinel: you just said that bzr+http was slated for inclusion in bzr-0.12, didn't you?
[10:31] <j-a-meinel> There is no bzr+http in 0.11, so it would have to be 0.12
[10:32] <j-a-meinel> There is a 'bzr://' which is a raw-socket protocol.
[10:32] <ddaa> okay, then I guess it's more "expected to be included in 0.12"
[10:32] <j-a-meinel> But it doesn't have any authentication
[10:32] <ddaa> sure, sure
[10:32] <j-a-meinel> And has not been vetted to make sure it is safe for anonymous.
[10:32] <j-a-meinel> (It *does* default to readonly mode)
[10:33] <ddaa> as lifeless is deeply involved in it, I'm quite confident there will be no glaring security hole
[10:33] <j-a-meinel> sure. nothing glaring. but security can be pretty subtle.
[10:33] <ddaa> "dude, don't use squid, lifeless dunno how to make a secure http server" :)
[10:35] <lifeless> ddaa: morning
[10:35] <ddaa> lifeless: morning
[10:35] <lifeless> ddaa: you want that skype call ?
[10:36] <ddaa> could be useful, I need to braindump a thing to a spec first
[10:36] <lifeless> sounds messy
[10:36] <ddaa> lifeless: in the meantime, can you have a look at https://devpad.canonical.com/~andrew/paste/file1NHVKc.html first
[10:36] <ddaa> the braindumpspeccing should give you enough time to digest that chunk
[10:37] <ddaa> then we'll talk about it
[10:40] <lifeless> ddaa: theres no scope
[10:40] <ddaa> oh
[10:40] <lifeless> which makes it hard for me to say 'maybe it should do X'
[10:40] <lifeless> or
[10:40] <lifeless> 'doing X would be out of scope'
[10:42] <ddaa> Scope is "process SVN logs so Adds combined with other operations in sub-paths are handled correctly, enable support for renaming and resurrection", bonus points are "remove uncessary remote directory listing operations, optimise data retrieval".
[10:43] <ddaa> currently, things like "A foo/bar (copied from blah), D foo/bar/baz" cause cscvs to crash
[10:43] <ddaa> that's bloking the python import
[10:43] <ddaa> and at least a dozen other svn imports
[10:44] <ddaa> renaming and resurrection will not be implemented at first, but that design should make that reasonably easy
[10:51] <ddaa> lifeless: to put it shortly, the scope is "make cscvs support for svn suck less"
[10:53] <lifeless> ddaa: some thoughts
[10:54] <lifeless> there appears to be to me too much magic
[10:54] <ddaa> mhmh, I see no magic here, explain
[10:54] <lifeless> when x is a ub expression of y it wont be evaluated -> the evaluator has to special case it
[10:54] <ddaa> ha right, you are reading the initial brain dump
[10:55] <lifeless> y can be simulataneously co-located with z, and when so has the special path ... more magic
[10:55] <ddaa> look for the class draft at the end, all the magic actually happens in the construction of the expression tree
[10:55] <ddaa> so evaluation is very straightforward
[10:55] <jelmer> yeah, connection here is kinda flaky
[10:56] <ddaa> lifeless: construction of the tree is the pathChanged method
[10:59] <ddaa> I agree the magic path bit is annoying, but it's necessary otherwise several classes need to explicitely make provisions for Modify changes.
[10:59] <ddaa> lifeless: I'm up on skype