[12:03] <kiko-afk> quite a nice flight if I may say so myself
[12:03] <jordi> cool
[12:04] <sivang> what were all you guys doing in nyc? ( jordi I've seen the photos ;-))
[12:05] <kiko-afk> I did pretty much NOTHING
[12:10] <jordi> kiko-afk: yay. :)
[12:10] <jordi> sivang: visit
[12:11] <kiko-afk> just walked around
[12:11] <kiko-afk> ate pizza
[12:11] <kiko-afk> saw the ex-wtc
[12:11] <kiko-afk> what else?
[12:15] <jordi> you went to the void?
[12:15] <jordi> heh
[12:15] <jordi> I didn't
[12:15] <jordi> everyone told me it wasn't worth going
[12:15] <jordi> we did go to the bull and the stock xchange
[12:15] <jordi> evil places
[12:18] <kiko-afk> the bull, huh? where is it?
[12:20] <sivang> jordi: saw you're photos standing there :)
[12:22] <jordi> kiko-afk: near the stock exchange
[12:22] <kiko-afk> somebody mentioned the bull but I had never heard of it.
[12:22] <kiko-afk> jordi, and what of the stock xchange -- is it madness?
[12:23] <jordi> kiko-afk: me neither. It seems to be the friendly symbolism for capitalism
[12:23] <jordi> kiko-afk: didn't let us in
[12:23] <jordi> but we tried
[12:24] <kiko-afk> I thought there were guided tours or something
[12:24] <kiko-afk> ex-wtc is a big hole in the ground
[12:25] <kiko-afk> surprisingly devoid of debris
[01:13] <mdz> kiko: you FROZE
[01:14] <kiko> well, in nyc I did
[01:14] <kiko> not here
[01:15] <ajmitch> a good thing I didn't bother going to the big hole in nyc then
[01:15] <kiko> ajmitch, the empire state is something to behold!
[01:15] <ajmitch> I got a photo from outside, but I was with friends
[01:16] <kiko> ex-wtc is interesting, actually, but more because of what it represents than what you can see there. though it is pretty ominously empty
[01:16] <ajmitch> yeah
[01:16] <ajmitch> it would have been a fairly long walk to see a hole though :)
[01:17] <kiko> it's a short metro ride!
[01:20] <lifeless> go forth and sleep dammit
[01:21] <Kinnison> but I just got back from the kinemax
[01:21] <Kinnison> most good it was, too
[02:05] <Kinnison> g'night all
[02:44] <tvon> Was there a change at some point that made bug report mails come from the submitter as opposed to some @bugs.launchpad.net address?
[02:45] <tvon> better yet, I have a use case for you that I suspect is pretty common
[02:46] <tvon> The group for my project has a mailing list address associated with it.  Whenever a bug is filed in Malone against the project a mail shoots to the mailing list.  This is perfect, except it seems the mails are coming from the submitters email address so the only way I can let the bug mails go directly through to the list is to open up the list to non-subscribers
[02:47] <ajmitch> tvon: we have that for universe-bugs with ubuntu
[02:47] <tvon> so the question would be, how can I get bug mails through to the mailing list without opening up the list to non-subscribers?
[02:47] <ajmitch> as you can imagine, there's a lot of traffic there
[02:47] <tvon> ajmitch: is the list open?
[02:48] <ajmitch> you have to match on a header
[02:48] <tvon> I would think, yes :)
[02:48] <tvon> aha
[02:48] <ajmitch> not sure if the list is open, but there are headers like X-Generated-By
[02:49] <tvon> X-Generated-By: Launchpad (canonical.com) ?
[02:49] <tvon> yeah, cool
[02:49] <ajmitch> & the Reply-To address is set to launchpad also
[02:49] <tvon> is this something you procmail or is it setup in mailman?
[02:49] <ajmitch> recent mailman, I believe
[02:49] <ajmitch> I don't run the list
[02:49] <tvon> okay
[02:50] <tvon> that should be enough for me to go on, thanks much
[02:57] <jamesh> tvon: you can use mailman 2.1's spam controls to allow messages with certain headers to be accepted
[02:58] <tvon> jamesh: thanks
[03:04] <tvon> sweet, all set
[03:04] <tvon> thanks folks
[05:23] <stub> lifeless: It looks like pqm is retrieving archives via sftp which can't be particularly fast. Is there a hook in PQM to make it rewrite URLs, so local archives are retrieved direct from the fs?
[05:24] <lifeless> stub: no
[05:24] <lifeless> stub: I'm about to move it to balleny
[05:26] <stub> Will belleny be working with local archives and pushing the results to chinstrap, or using the archives on chinstrap directly?
[05:43] <jamesh> lifeless: does pqm accept the branchname;revno=NNN syntax for the star-merge command?
[06:01] <lifeless> stub: local master, pushes results
[06:01] <lifeless> but merges from user archives on chinstrap
[06:09] <lifeless> jamesh: hmm, dont think bzr has been taught that
[06:09] <lifeless> patches desired :)
[06:09] <jamesh> lifeless: the pending-reviews code handles it internally
[06:09] <lifeless> yeah
[06:09] <lifeless> nice
[09:35] <sivang> Morning all
[09:37] <StevenK> I sent a mail to<EMAIL_ADDRESS>and I haven't seen the bug turn up or gotten any mail back from launchpad. It was sent at 22/11 22:30 +1100 from<EMAIL_ADDRESS>[09:46] <BjornT> StevenK: it seems that for some reason your signature couldn't be verified. i'll take a look at it today.
[09:53] <StevenK> BjornT: Right.
[10:17] <zyga> morning
[10:17] <zyga> has aynone seen carlos?
[10:17] <stub> lifeless: Even using the head of your integration branch, I can't rsync $rocketfuel/launchpad/devel and 'bzr revert' in it. Is there another branch I can use for doing rollouts?
[10:20] <carlos> morning
[10:21] <zyga> carlos: hi, do you have a moment?
[10:21] <zyga> carlos: a lenghy moment mayb
[10:22] <zyga> ... a lengthy moment, maybe
[10:22] <carlos> give me 15 minutes, please...
[10:22] <zyga> right, thanks
[10:38] <carlos> zyga, hi
[10:38] <zyga> okay
[10:38] <zyga> I'm in contact with a group of translators known as gnomepl.org
[10:39] <zyga> I've just managed to convice them to move _all_ of their work over to rosetta
[10:39] <zyga> they have a cvs repo with translations relevant to every official gnome application
[10:39] <zyga> now we are wondering how to move all of that over to rosetta
[10:40] <zyga> rosetta probably has the outdated versions since they upload their stuff to cvs.gnome.org every now and then and that's how we got our stuff, right?
[10:40] <carlos> zyga, first, we need to import GNOME into Rosetta
[10:40] <zyga> the official gnome?
[10:40] <carlos> after that, I suppose you can use curl to create a script that imports those .po files (unless they are not already inside GNOME's CVS
[10:40] <carlos> )
[10:40] <zyga> (they upload to official gnome, they are *the* upstream as far as pl_PL is concerned)
[10:41] <carlos> ok, then it's a matter of implement the bridge between cvs -> Rosetta
[10:41] <zyga> also there is an issue of automatic exports from rosetta back to cvs.gnome.org
[10:41] <carlos> well, between l10n-status.gnome.org -> Rosetta
[10:41] <zyga> right
[10:41] <carlos> zyga, no way to do that now
[10:41] <zyga> exactly
[10:41] <zyga> hmm
[10:42] <zyga> is there any way to automatically export from rosetta to po?
[10:42] <carlos> zyga, that part should be handled by them
[10:42] <zyga> (like, without all the waiting and getting emails)
[10:42] <carlos> zyga, we can implement something specific for this use case, yes
[10:42] <zyga> good
[10:42] <zyga> then the rest is easy
[10:42] <zyga> so the plan is:
[10:42] <zyga> 1) make sure that rosetta has all the packages that we have, all the domains
[10:43] <zyga> 2) upload from cvs.gnomepl.org (note the .pl) stuff to rosetta, manually
[10:43] <zyga> 3) triple check that everything is fine
[10:43] <zyga> 4) work on a way to export stuff from rosetta to po automatically and then (that's our part) back to cvs.gnome.org
[10:43] <carlos> zyga, why is the 2) step needed?
[10:44] <carlos> if they upload their translations into cvs.gnome.org
[10:44] <carlos> that's enough... right?
[10:44] <zyga> right but their repo is synced only like, at each gnome released
[10:44] <zyga> s/d$//
[10:44] <zyga> so it's been updated already with bugfixes but those changes never made back to cvs.gnome.org
[10:45] <zyga> there were some management problems, people with upstream cvs access had no time to work on this
[10:45] <zyga> one more issue, more ubuntu specific
[10:45] <carlos> ok
[10:46] <zyga> if say, we upload translation of gnome-panel (to the g-p package) will ubuntu's (say, dapper) variant of g-p automatically pick up the changes?
[10:46] <zyga> I understand those are separate, right?
[10:47] <zyga> hmm, strange: https://launchpad.net/products/gnome-panel/+series/main
[10:47] <zyga> no breezy, no dapper?
[10:48] <carlos> zyga, no directly, but we are going to implement a UI to manage translation shares between releases
[10:48] <zyga> carlos: is there any bridge for upstream to pull translations back or is that a manual process? like for something as big as gnome
[10:48] <carlos> zyga, if you translate with Rosetta you will be able to choose if the translation should apply too to Breezy, dapper or any other release)
[10:49] <carlos> zyga, manual process, in the future, we will have a bzr branch
[10:49] <zyga> hmm AFAIR I choose that by url
[10:49] <carlos> where maintainers will be able to get all translations from Rosetta
[10:50] <carlos> zyga, https://launchpad.net/products/rosetta/+spec/multicast-translations <- This spec has a description of the procedure we are going to implement to share translations with other releases/branches
[10:51] <zyga> reading
[10:52] <zyga> carlos: is there any 'mess' in the product list? like multiple 'variants' of the same product being registerd, anything that could significantly increase the difficulty of our transition?
[10:53] <carlos> zyga, don't think so
[10:54] <zyga> so we should move all of our stuff into official products, not to any branded variants, right?
[10:56] <carlos> right
[10:57] <carlos> this movement will be done for all GNOME translation teams
[10:57] <carlos> so we need to do a full import
[10:57] <zyga> hmm?
[10:57] <carlos> so any other team can use Rosetta
[10:57] <carlos> if they want
[10:57] <zyga> there are other teams using rosetta as their primary tool?
[10:57] <carlos> so we should not import only 'pl'
[10:58] <zyga> oh, ok
[10:58] <carlos> zyga, I think there are a couple of teams wanting to use it, yes
[10:58] <carlos> and I suppose others would be interested if we provide the infrastructure
[10:59] <zyga> okay
[10:59] <zyga> I'll inform the grou
[10:59] <zyga> group
[10:59] <zyga> can you give any timeframe for the rosetta->po export on demand?
[11:00] <zyga> (anything that can be automated is fine)
[11:00] <zyga> simply the current email based system is difficult to automate
[11:02] <carlos> zyga, I think the main problem is the l10n-status -> Rosetta path
[11:02] <zyga> hmm, why?
[11:02] <carlos> without that... the export to .po is no so useful
[11:02] <zyga> that needs to be done once I guess
[11:02] <carlos> not really
[11:03] <zyga> the exactly opposite path needs to be done regularly
[11:03] <carlos> we need to get the updates
[11:03] <zyga> hmm
[11:03] <carlos> or Rosetta will be out sync soon
[11:03] <zyga> okay, right
[11:03] <zyga> I assumed everyone would work with rosetta but that's a big 'if'
[11:03] <zyga> hmm
[11:03] <zyga> I've got an idea
[11:04] <zyga> cvs.gnome.org -> we pull all translations, tagged manually (from .po to our product), then we fetch a snapshot of bzr tree with relevant .po file and copy it over (maybe msgmerge, I don't know how to handle the overlap and conflict part really), then we commit back to bzr
[11:05] <carlos> I don't think all teams will want to use Rosetta...
[11:05] <zyga> actually the conflict part is important
[11:05] <carlos> zyga, how do you update Rosetta in that workflow?
[11:06] <zyga> from our bzr tree (where our is rosetta)
[11:06] <zyga> similarly to the way imports are done manually today
[11:06] <zyga> you queue all the modified files for import
[11:06] <zyga> and the results are feed to team leaders (or some public site) for review
[11:07] <zyga> that's lots of work to get right but not so much work to get working I guess
[11:09] <zyga> I'm not sure how rosetta's back end work so I'm guessing based on what I know from the front-end
[11:09] <carlos> zyga, the bzr -> Rosetta path needs to be done manually.... that's a big amount of work
[11:09] <zyga> why?
[11:10] <zyga> I can queue a .po for import today
[11:10] <zyga> why cannot that be put into some for loop?
[11:11] <carlos> zyga, will you queue all GNOME .po files ?
[11:11] <zyga> not manually for sure
[11:11] <carlos> that's my point
[11:11] <carlos> ;-)
[11:11] <zyga> but we can tag from /specific/path/in/the/gnome/cvs to a tuple (our-product,some-other-data-we-need)
[11:11] <zyga> that's manual but one time job
[11:12] <zyga> that's about what, 50-150 associations, righT?
[11:18] <carlos> zyga, we should use l10n-status.gnome.org to get updated .pot files
[11:18] <SteveA> stub: hello
[11:18] <carlos> GNOME's CVS does not have .pot files
[11:18] <stub> SteveA: Morning
[11:18] <SteveA> moin
[11:18] <SteveA> so, i'm doing this code review for carlos
[11:18] <zyga> calos: is that something different from cvs.gnome.org?
[11:18] <zyga> ah
[11:18] <zyga> the pot files, right
[11:18] <SteveA> in many of his page templates, there's a section underneath the h1 to iterate over notices and alerts and display them.
[11:19] <zyga> (sorry I had a phone call)
[11:19] <SteveA> i'm surprised to see this here, and not in the main template.
[11:19] <SteveA> can you tell me about it?
[11:19] <lifeless> stub: let me test
[11:19] <zyga> carlos: hmm, do we keep individual versions, like 2.12, 2.14?
[11:19] <zyga> or just the head?
[11:19] <SteveA> i have some work to do on the main template shortly, so i can refactor this into it, if that will work
[11:20] <stub> SteveA: If it is the BrowserNotification stuff, it should be in the main template (and only the main template). That was where I left it anyway.
[11:20] <SteveA> > +  <p tal:repeat="alert view/alerts"
[11:20] <SteveA> > +    class="portalMessage"
[11:20] <SteveA> > +    tal:content="alert">
[11:20] <SteveA> > +    Notification Message
[11:20] <SteveA> > +  </p>
[11:20] <SteveA> > +  <p tal:repeat="notice view/notices"
[11:20] <SteveA> > +    class="portalMessage"
[11:20] <SteveA> > +    tal:content="notice">
[11:20] <SteveA> > +    Notification Message
[11:20] <SteveA> > +  </p>
[11:20] <SteveA>
[11:20] <SteveA> that kind of thing
[11:20] <SteveA> maybe that's not notification messages then
[11:20] <SteveA> carlos: ?
[11:21] <carlos> SteveA, I added it following the hacking FAQ
[11:21] <stub> Sounds like some atrophied documentatin
[11:21] <SteveA> it irks me to see this repeated stuff in many templates
[11:21] <SteveA> okay, thanks stub and carlos.  i'll look into it some more.
[11:21] <carlos> How should I generate notices like "Added Bug #1234" to the top of the page?
[11:21] <stub> SteveA: I think this was the way someone documented notifications before BrowserNotifications existed
[11:21] <Ubugtu> Error: I cannot access this bug
[11:22] <carlos> that entry
[11:22] <carlos> at https://wiki.launchpad.canonical.com/LaunchpadHackingFAQ
[11:26] <stub> carlos: response.addInfoNotification(...), response.addNoticeNotification(...) etc. The interface that describes these is canonical.launchpad.webapp.interfaces.INotificationResponse
[11:26] <stub> carlos: As per BrowserNotificationMessages spec
[11:27] <zyga> carlos: so what should I suggest to the group now
[11:27] <zyga> carlos: we either wait and work on the automatic backend
[11:27] <zyga> carlos: or we do that manually
[11:27] <carlos> stub, Ok, thanks
[11:27] <carlos> stub, could you update the FAQ page, please?
[11:27] <lifeless> SteveA: is there a review team meeting tonight ?
[11:28] <lifeless> SteveA: ... what time ?
[11:29] <carlos> zyga, hmmm don't know, I cannot implement the needed bits atm but I will try to develop it as part of my next three months of work...
[11:30] <lifeless> stub: so debugging this
[11:30] <lifeless> stub: 'branch launchpad/devel' works
[11:30] <lifeless> which suggests there is working tree state that is confusing things
[11:31] <zyga> carlos: is there any way we/i can help?
[11:31] <SteveA> lifeless: there is none planned.
[11:31] <carlos> zyga, hmmm, yes
[11:32] <carlos> zyga, there are several things to do
[11:32] <stub> lifeless: I'll try just rsyncing the .bzr directory (?)
[11:32] <jordi> carlos, SteveA, kiko-zzz: a mail of max interest is about to hit rosetta-users
[11:33] <carlos> 1.- Create any missing product
[11:33] <jordi> mailman upstream wonders about copyright issues, while thinking of adopting rosetta for mailman
[11:33] <carlos> 2.- Create the current branches for those products (gnome-2.12, main, etc...)
[11:33] <carlos> jordi, cool!!!!
[11:34] <zyga> carlos: do I need any special priviledges for that?
[11:34] <lifeless> stub: now I'm copying devel with .bzr
[11:34] <lifeless> and trying a revert
[11:34] <lifeless> I'm guessing a bug in revert tbh
[11:34] <carlos> zyga, I don't think so, we will need to change the ownership later, but it's not a big deal....
[11:35] <jordi> carlos: this reopens a few new questions I raised in that London sprint
[11:36] <jordi> how to handle GNU packages
[11:36] <jordi> we probably want sabdfl's input here.
[11:36] <jordi> is he around these days?
[11:36] <carlos> zyga, 3.- If you create a script that gets files from l10n-status.gnome.org and prepare it to know the branch, the product and the file at some point so I can integrate it into launchpad... then most of the work would be done
[11:36] <lifeless> SteveA: we should start those again, no ?
[11:36] <jordi> carlos, SteveA: any comments on the new uploads policy?
[11:37] <jordi> David Farning is flooding me with requests :)
[11:37] <carlos> jordi, GNU packages should have the GNU teams created as GNOME, Ubuntu or KDE
[11:38] <carlos> so only them can do translations
[11:38] <jordi> carlos: even so, we have the disclaimer issue.
[11:38] <carlos> jordi, will try to do it today
[11:38] <jordi> and the licence
[11:38] <jordi> under what licence are Rosetta translations?
[11:39] <carlos> jordi, ... if we block the teams like we do with GNOME... only official team coordinators will be able to add new translators to the team
[11:39] <carlos> jordi, the same as the product we are translating
[11:39] <SteveA> lifeless: yes. i want kiko to be involved, and for whatever reason he often wasn't attending before.
[11:39] <carlos> + one that allows us to reuse the translations with other products
[11:39] <jordi> carlos: ok
[11:39] <carlos> zyga, what I'm not completely sure is about the legal issues with that....
[11:39] <SteveA> jordi: who is David Farning?
[11:39] <jordi> SteveA: dunno. Someone who wants to translate APT.
[11:39] <carlos> jordi, the 'legal' link says that
[11:40] <zyga> hmmm
[11:40] <zyga> carlos: what could be the problem?
[11:40] <carlos> SteveA, would be a big problem if zyga develops a script that will be executed on production and integrated by me inside launchpad?
[11:41] <SteveA> jordi: is he someone who wants to translate APT upstream?
[11:41] <jordi> SteveA: yes. He even feeds me with the pot and po files
[11:41] <SteveA> carlos: tell me about what the script is for
[11:41] <SteveA> jordi: is he involved in the upstream project?
[11:41] <jordi> no
[11:41] <SteveA> has he contacted them?
[11:41] <carlos> SteveA, to do automatic imports from l10n-status.gnome.org into Rosetta
[11:42] <jordi> probably not
[11:42] <jordi> he also feeds me with postgresql templates
[11:42] <carlos> SteveA, he would do all the development that is not launchpad specific and then I will add the missing bits to do the final imports into our database using launchpad's code
[11:42] <jordi> this is why I ask about oyur policy draft.
[11:42] <SteveA> jordi: okay, let's take a look at it.  can we look in 30 mins?
[11:43] <SteveA> carlos: is this good for you too?
[11:43] <carlos> SteveA, yes
[11:43] <jordi> So we can publish it, and direct everyone to it, so they have the new policy in mind when requesting stuff.
[11:43] <jordi> ste	sure thing
[11:44] <SteveA> carlos: does l10n-status.gnome.org have just stats, or also translation data?
[11:44] <carlos> SteveA, translation data
[11:44] <carlos> SteveA, so we can get from there the .pot and .po files in a easy way
[11:44] <lifeless> stub: confirmed, its teh revert of a file in a subdir
[11:45] <carlos> easier than direct cvs download
[11:45] <zyga> carlos:  just a side question, I don't see the .pot files anywhere on l10n-status.g.o
[11:45] <lifeless> stub: I'll fix it tomorrow
[11:45] <SteveA> okay.  so, if zyga makes some code available that is under a reasonable open source licence, then zyga can publish it and give it to anyone.  we can use it (put it in lib/contrib) and you can import it to use as part of launchpad
[11:45] <zyga> GPL is fine for me
[11:46] <carlos> zyga, http://l10n-status.gnome.org/gnome-2.14/PO/at-spi.HEAD.pot
[11:47] <SteveA> carlos: note that you won't be planning to alter zyga's code, but import it and use its API
[11:47] <carlos> SteveA, it will call launchpad code
[11:47] <zyga> I didn't see that directory, I'll be very helpful :-)
[11:47] <carlos> SteveA, oh, ok
[11:47] <zyga> you can even hire me for 0$ and get full rights
[11:48] <SteveA> carlos: it is doing a generic job.
[11:48] <SteveA> that is, it is getting stuff, and passing it along somewhere else
[11:48] <SteveA> we just ought to have that "somewhere else" as something pluggable
[11:48] <SteveA> also we need to think about tests for code that goes into launchpad
[11:48] <SteveA> but you can test the launchpad part in our usual ways
[11:49] <carlos> good idea
[11:49] <carlos> that way others interested on KDE imports
[11:49] <carlos> could develop a file with the same API
[11:49] <carlos> so we can integrate it in the same way....
[11:49] <carlos> zyga, How does it sounds?
[11:50] <zyga> carlos: fine :-)
[11:50] <zyga> carlos: any language suits you? I'll be prototyping in bash probably
[11:50] <SteveA> zyga: i'd recommend the LGPL
[11:50] <SteveA> and python
[11:50] <zyga> k
[11:50] <carlos> zyga, yes, python, please...
[11:51] <carlos> zyga, let me look into jordi's email and we will talk about this later, ok?
[11:52] <zyga> fine
[11:52] <zyga> thanks
[11:53] <carlos> zyga, thanks to you for your offer
[12:00] <cprov> morning guys
[12:01] <zyga> carlos: the thing is in motion, gnomepl.org is notified and I'm looking into the script
[12:02] <carlos> cool
[12:02] <carlos> zyga, I think you will need the .xml file we are using to generate the l10n-status.gnome.org pages
[12:03] <carlos> zyga, at least as a hint so you don't need to parse .html code
[12:03] <zyga> carlos: could be useful :-)
[12:03] <zyga> carlos: we?
[12:03] <matsubara> good morning!
[12:04] <carlos> zyga, yeah
[12:04] <carlos> jordi, I think it's ok
[12:05] <carlos> jordi, the only addition I think you should do there is about upstream imports of GNOME and KDE products
[12:05] <zyga> carlos: so how do I get that .xml file?
[12:05] <BjornT> if bzr tells me that there were conflicts while merging, how do i get bzr to tell me in which files the conflicts occurred?
[12:05] <carlos> those will be done automatically and we will get the updates automatically too so it's an exception
[12:05] <carlos> jordi, also the translators will be locked to be the same as upstream
[12:06] <carlos> zyga, it's at cvs.gnome.org
[12:06] <carlos> zyga, but I can copy it to l10n-status.gnome.org so it's easier for you
[12:06] <jordi> carlos: for GNU/Debian/KDE/GNOME you mean?
[12:06] <carlos> jordi, for any upstream imports, yes
[12:06] <carlos> the main targets now are GNOME and KDE
[12:06] <zyga> carlos: please do
[12:06] <niemeyer> Good morning
[12:07] <carlos> niemeyer, matsubara morning
[12:07] <matsubara> BjornT: bzr conflicts?
[12:07] <carlos> zyga, oh, we have it already :-P
[12:08] <carlos> http://l10n-status.gnome.org/translation-status.xml
[12:08] <carlos> zyga, it's updated automatically with every page updated
[12:08] <carlos> s/updated/update/
[12:08] <jordi> carlos: not for "any". There are imports that just don't have any kind of translation group behind
[12:09] <carlos> jordi, any handled automatically and that has their own translation team. Better now?
[12:09] <jordi> handled automatically?
[12:09] <SteveA> BjornT: talk to jblack about what documentation you'd like to see.
[12:09] <SteveA> lifeless: ain't that so?
[12:09] <carlos> jordi, yes, zyga is going to help us to do automatic imports from GNOME into Rosetta
[12:09] <carlos> jordi, with a script, just like Ubuntu imports
[12:10] <jordi> oh, ok. I was talking about imports in general
[12:10] <jordi> ok
[12:10] <BjornT> matsubara: thanks, didn't know about that command. too bad it didn't tell me anything, though
[12:11] <sivang> zyga: how is that going to work , out of curiosity?
[12:11] <BjornT> SteveA: ok, i will. i good start would be that 'bzr help' told me all the commands that are available
[12:14] <SteveA> BjornT: the last item with 'bzr help' is 'bzr help commands  list all commands'
[12:14] <SteveA> carlos, jordi: it is time
[12:15] <carlos> ok
[12:16] <SteveA> what wiki page should i look at?
[12:17] <carlos> SteveA, jordi sent it by email
[12:18] <SteveA> ok
[12:18] <BjornT> SteveA: hmm, don't know how i managed to miss that. probably because it was grouped together with an example.
[12:19] <SteveA> would you call gettext an application?
[12:19] <SteveA> i'm thinking that products in launchpad are applications and libraries and perhaps other things too
[12:20] <carlos> SteveA, gettext has commands too so it's also an application...
[12:20] <jordi> SteveA: is that question related to the doc?
[12:21] <SteveA> yes
[12:21] <zyga> sivang: as far as I understand: fetch stuff from l10n-status.gnome.org, create tuple: (product, branch, language-list) and be able to use that data to get a .po for every language and the .pot for every branch
[12:22] <SteveA> so, i want to talk about what "rosetta official" means
[12:22] <jordi> yeah, that isn't clear enough.
[12:22] <SteveA> i can think of two realted, but different things
[12:23] <SteveA> 1. when rosetta is the main way that an application is translated
[12:23] <jordi> SteveA: what's the other one?
[12:23] <sivang> zyga: sounds simple enough to be cool :)
[12:23] <SteveA> 2. when the application mantainer is happy with people using rosetta for translating it, and will sync up with rosetta (both directions) often
[12:24] <SteveA> i guess the distinction doesn't matter, as far as translators are concerned, provided that in the second case the syncing happens well and often
[12:24] <zyga> sivang: I sure hope so
[12:25] <carlos> zyga, yeah, it's that more or less
[12:25] <carlos> SteveA, right
[12:25] <lifeless> SteveA: aint what so ?
[12:26] <SteveA> SteveA BjornT: talk to jblack about what documentation you'd like to see.
[12:26] <SteveA> SteveA lifeless: ain't that so?
[12:26] <zyga> carlos: can you recommend xml-io and url-io stuff? :)
[12:26] <zyga> pycurl for the latter lacks docs
[12:27] <zyga> various python-to-xml serializers produce crappy output
[12:27] <SteveA> python has urllib and httplib in the standard library
[12:27] <carlos> zyga, we use urllib2 for http
[12:27] <SteveA> also in the standard library
[12:28] <carlos> about xml... SteveA, any suggestion?
[12:28] <SteveA> what's the xml for?
[12:28] <SteveA> and, can we please focus on translation policy for a few more minutes...
[12:29] <carlos> sure, sorry
[12:29] <SteveA> jordi: the doc reads well.  it does presuppose that the reader understands the distinction we make between packages and products
[12:29] <SteveA> i was confused by that, so that's why i asked carlos a bunch of questions and drew that diagram
[12:30] <SteveA> that is, i was confused by how translations work with respect to packages and to products in rosetta
[12:30] <jordi> SteveA: would an explanation of both at the begining work?
[12:30] <jordi> SteveA: that is covered by the doc, is it?
[12:30] <jordi> I mean, I talk about how both work
[12:31] <jordi> one is byhand, the other automatic
[12:31] <SteveA> that says how the templates get into rosetta
[12:31] <SteveA> it doesn't explain why the package ones aren't the same as the product ones
[12:31] <jordi> ok
[12:31] <SteveA> or why someone would translate one rather than the other
[12:31] <jordi> will clarfy
[12:32] <jordi> where does this belong? launchpad wiki or ubuntu?
[12:32] <SteveA> launchpad wiki
[12:32] <SteveA> as it is about the policy for upstream
[12:32] <SteveA> also, the doc should read more like "this is the policy"
[12:32] <jordi> ok
[12:32] <SteveA> rather than in terms of old policy and here's a new policy
[12:32] <lifeless> lamont-away: yes, jblack is the doco king
[12:32] <SteveA> because it is stating what we intend to do now
[12:32] <jordi> nod
[12:32] <jordi> ok 1 - "This is the policy"
[12:33] <jordi> 2 - Clarify distro vs products
[12:33] <jordi> 3 - permissions for GNOME/KDE/GNU/etc packages
[12:33] <jordi> I think that's it.
[12:33] <SteveA> i think the policy is good.  we should go with it for a while, and see how translators and upstream maintainers respond to it.  keep a careful note of places where there's a problem, where there are people who want to translate, but the upstream isn't keen on it.
[12:33] <SteveA> i think the "official rosetta" thing needs some refinement
[12:34] <jordi> ok
[12:34] <sivang> bit OT, if I have an Ubuntu bug - can I report it in malone or should I report it in bugzilla ?
[12:34] <SteveA> i can see that some projects (like Silva) who have chosen to use rosetta as their primary place for translation would accept the "official rosetta project" tag
[12:34] <SteveA> sivang: if it is in Main, bugzilla.  Universe, launchpad.
[12:35] <SteveA> but, i can see people being surprised and maybe a little taken aback, if they say "yeah, we're cool with rosetta" and suddenly they're "official rosetta users"
[12:35] <SteveA> the doc should say "here's what 'official rosetta-using project' means:"
[12:35] <sivang> SteveA: ah still? I would have thought starting to open new main bugs in launchpad could mean more "QA" cycles for malone, what's holding back from using malone as primary bug tracker?
[12:35] <SteveA> and that means either
[12:36] <SteveA> 1. rosetta is the primary means of translation for this, or
[12:36] <SteveA> 2. someone is making the commitment to sync often with CVS or whatever
[12:36] <SteveA> and also, maybe we should make that distinction in the data model for products.  carlos?
[12:36] <SteveA> sivang: we're importing the stuff from bugzilla into launchpad really soon.
[12:37] <SteveA> the software is written. it is being tested on staging now
[12:37] <carlos> SteveA, I suppose it's a matter of expand the current data model
[12:37] <carlos> so we have Rosetta official, Rosetta friendly or don't care at all
[12:37] <jordi> SteveA: what's the meaning of "official", in your eyes?
[12:37] <SteveA> rosetta primary, rosetta will-sync, unknown
[12:38] <carlos> jordi, when upstream will only accept translations from Rosetta
[12:38] <jordi> nod
[12:39] <sivang> SteveA: ah ok, good
[12:39] <SteveA> it's really about where the integration occurs
[12:39] <SteveA> does it occur in rosetta?  does it occur elsewhere?  does it not occur.
[12:40] <sivang> for the record, I would prefer hundred times more using malone istead of the slow bugzilla to report bugs :)
[12:40] <jordi> well, there's no real "integration" right now.
[12:40] <jordi> not until bzr exports
[12:40] <SteveA> in the case where rosetta is the primary means of translation, integration occurs in rosetta
[12:40] <SteveA> there's a lot of effort in the rosetta code and tests to do that well
[12:41] <SteveA> in the case where rosetta is used as a source of translations, and is synced often, then rosetta is still an important tool for integration, but the process is run externally to rosetta
[12:41] <SteveA> by someone who is interested in these things, from upstream
[12:42] <SteveA> when the situation is unknown, probably no integration occurs, and people get annoyed that they are doing repeated work, or their work is not used.
[12:42] <carlos> so the first case is Ubuntu's case, right?
[12:42] <carlos> with language packs
[12:42] <SteveA> who will keep track of when the policy hasn't worked well, of when there are willing translators of a product, but upstream aren't interested yet?
[12:43] <SteveA> carlos: i don't think ubuntu is in this part of the model.  the policy doesn't apply, because it applies only to products.  not to distros or SPs
[12:43] <carlos> SteveA, then the option #1 will not be possible at all until we have the bzr integration
[12:44] <carlos> for products
[12:44] <SteveA> option number one being?
[12:44] <SteveA> the product Silva is already a "rosetta-primary" product.
[12:45] <carlos> in the case where rosetta is the primary means of translation, integration occurs in rosetta
[12:45] <SteveA> sure, there's no fancy bzr integration
[12:45] <carlos> SteveA there's a lot of effort in the rosetta code and tests to do that well
[12:45] <SteveA> but they don't do any translation now, except via rosetta
[12:45] <SteveA> they download new po files from rosetta
[12:45] <carlos> SteveA, then I don't see the difference with the option of 'in the case where rosetta is used as a source of translations, and is synced often, then rosetta is still an important tool for integration, but the process is run externally to rosetta"
[12:45] <SteveA> they don't do translation in their CVS
[12:45] <carlos> ok
[12:45] <SteveA> so, there is no syncing to do
[12:45] <SteveA> it is simple
[12:45] <SteveA> they just get translations from rosetta
[12:45] <carlos> I see it now
[12:46] <SteveA> http://www.infrae.com/newsitems/silva_translations
[12:46] <SteveA> here
[12:46] <SteveA> nice example
[12:47] <carlos> SteveA, ok
[12:49] <SteveA> jordi: please also add to the doc that we'll review this policy at the end of January
[12:49] <SteveA> carlos, jordi: who will keep track of when the policy hasn't worked well, of when there are willing translators of a product, but upstream aren't interested yet?
[12:50] <carlos> jordi, would you do it ?
[12:52] <zyga> guys
[12:52] <zyga> #ubuntu-translators have been working on a wiki page for translator newcomers
[12:53] <zyga> http://wiki.ubuntu.com/TranslationTeam
[12:53] <zyga> it might be interesting for you
[12:53] <carlos> zyga, cool, thanks
[12:54] <zyga> we intend to promote that as the entry portal for all translators
[12:54] <carlos> we should point there as part of the RosettaFAQ
[12:54] <zyga> the main wiki
[12:54] <zyga> :-)
[12:54] <carlos> jordi, could you add it as the answer for... 'How could I translate Ubuntu?' or something like that
[12:55] <zyga> jordi: please join #u-translators, and take a look at the wiki in question
[12:59] <carlos> SteveA, anything else?
[12:59] <SteveA> i'd like to hear from jordi before we end the meeting
[01:00] <SteveA> but i think we have a workable plan for this now
[01:00] <SteveA> carlos: we need a bug for extending the 'official rosetta project' flag
[01:01] <carlos> ok, I will handle that
[01:01] <SteveA> thx
[01:03] <salgado> hey SteveA
[01:07] <BjornT> hmm, has anyone seen this error before while running tests? *** glibc detected *** double free or corruption (!prev): 0x09b90b70 ***
[01:07] <matsubara> I've seen
[01:08] <zyga> BjornT: 99% it's an application bug
[01:08] <BjornT> matsubara: did you find out what the problem was? (or how to work around it?)
[01:09] <matsubara> BjornT: nope :(
[01:10] <matsubara> BjornT: but apparently the tests are running fine...
[01:10] <jordi> sorry, was afk
[01:11] <BjornT> matsubara: not for me, the test run is aborted
[01:12] <StevenK> I keep seeing that with Perl using readline. The exit() handler gets tied up in knots and does that and cops a SIGABRT for its trouble.
[01:12] <StevenK> However, my knowledge of perlguts is nil, at best. :-)
[01:14] <matsubara> BjornT: let me know if you find out why this is happening.
[01:15] <sivang> lifeless: would you be able to toss me a link to the relevant debian-devel thread re:automated testing ?
[01:16] <jordi> SteveA, carlos: please excuse me, I'm busy for the next 15 mins at the office
[01:16] <jordi> will reply to this soon
[01:17] <carlos> ok
[01:19] <carlos> jordi, I will go out to have lunch so I will be out for a couple of hours
[01:19] <carlos> that will be in about 30 minutes or so
[01:20] <jordi> ok
[01:22] <SteveA> BjornT: if you get it reproducable, send details to jamesh
[01:22] <SteveA> jordi: okay.  please say if you get busy in the office, so we're not left hanging
[01:23] <jordi> ok
[01:24] <BjornT> SteveA: i could tar down the working tree and see if it's reproducable on another machine. but in a clean launchpad tree the same test passes, and i haven't made any changes that should affect the test
[01:28] <SteveA> carlos: sent you review
[01:28] <carlos> SteveA, thanks!
[01:29] <SteveA> BjornT: probably something subtle in a C extension not cleaning up after itself
[01:29] <SteveA> if it does fail predictably for you, it is worth trying elsewhere
[01:29] <SteveA> with exactly the same tree
[01:29] <BjornT> yeah, i'll do that
[01:30] <jordi> SteveA: am I suposseed to get one of those review mails from claire?
[01:32] <carlos> zyga, I need to leave now to have lunch, could we talk about the API for your python code when I'm back?
[01:36] <zyga> carlos: sure
[01:37] <Kinnison> Gods, if I was feeling less generous, I'd blacklist "Barry Warsaw" from my mail servers
[01:38] <Ubugtu> Malone bug #4746: Launchpad does not accept older GPG fingerprint formats Fix req. for: launchpad (upstream), Severity: Major, Assigned to: Nobody, Status: New http://launchpad.net/malone/bugs/4746
[01:39] <Kinnison> The least he could have done is set his launchpad preferred email to one which doesn't generate the autoreply
[01:44] <SteveA> Kinnison: you missed the "... because <reason>" out from the comment on the bug
[01:44] <SteveA> or whether we ever wil do so
[01:44] <SteveA> jordi: yes.  they haven't been sent out yet.  will be a little later today
[01:45] <jordi> SteveA: ok
[01:46] <Kinnison> SteveA: I realised that after submitting, and was going to go back and be more helpful, and then his autoresponder pissed me off
[01:46] <salgado> SteveA, would you like to talk about that ProperSignUpWorkflow spec?
[01:46] <Kinnison> SteveA: when I'm less angry, I'll go back and explain more
[01:48] <SteveA> Kinnison: if only we could file bugs on People
[01:48] <SteveA> you could file one on barry
[01:52] <SteveA> seems it sends just one email to an address
[02:00] <Kinnison> right
[02:03] <kiko> morning
[02:10] <jordi> SteveA: damn, I missed you.
[02:10] <jordi> I don't know if I have the "official" stuff too clear.
[02:21] <kiko> jordi?
[02:25] <stub> jamesh: I just killed your pqm merge btw - cscvs tests strike again.
[02:26] <WaterSevenUb> just wondering... is someone developing Rosetta documentation at the moment which is not available in the wiki?
[02:27] <WaterSevenUb> howto translate, howto use rosetta for project translation, howto.... stuff like that
[02:31] <jordi> kiko
[02:34] <kiko> stub!
[02:34] <kiko> how's it going man?
[02:34] <stub> kiko: Good enough
[02:34] <kiko> jordi, what did you miss from SteveA?
[02:34] <kiko> has anyone seen mpt around?
[02:34] <stub> kiko: So is Gina ready as far as you are concerned?
[02:34] <jordi> what to add regarding what "official rosetta" means
[02:34] <jordi> kiko: goood morning dude
[02:35] <kiko> stub, she is. let me check if rf contains all my patches.
[02:36] <stub> kiko: Anyone else need to give their stamp of approval to her?
[02:36] <kiko> not that I'm aware of
[02:37] <kiko> gustavo found a little bug in an error message I will fix now
[02:37] <stub> ok. So we are ready to go as soon as I land this LibrarianGarbageCollection branch and test it on staging
[02:38] <Kinnison> stub: define "ready to go" ?
[02:38] <stub> Kinnison: Run Gina on production against warty, hoary and breezy all architectures
[02:39] <stub> Kinnison: Or have you got a spanner to contribute to the works?
[02:39] <Kinnison> stub: I wouldn't do that until mdz is happy
[02:40] <Kinnison> stub: it'd be an arse to have to nuke it out of the production db and run her again
[02:41] <stub> kiko: Do you know if mdz is happy with the current state? Or does he need to have another look? Gina hasn't been run on staging since UBZ so I'd assumed he was happy with the state.
[02:42] <kiko> stub, we had a meeting yesterday about this. there are inconsistencies in the original archive that makes it difficult to parse the entire diff, but the general feeling was we should keep running it on staging until we have something that mdz and I bless as golden. the last run we were still missing some headers, a problem which we believe Kinnison has fixed
[02:42] <kiko> stub, I spoke to elmo yesterday and he said that staging was starting to get really full. I assume this is because the librarian is getting full of gina-produced stuff, right?
[02:43] <stub> Yes
[02:44] <kiko> stub, so let me just check that rocketfuel has all my latest patches and we should be good for a re-run
[02:45] <stub> ok. I'll land LibrarianGarbageStorage tonight, if pqm is nice, and run it against staging tomorrow. And then Gina again. You want I clean out all the records again or sync with the production db?
[02:46] <kiko> stub, syncing the production db sounds good -- we'd like to do a full run (though tbh the issues we found were in the publisher -- gina is unchanged from her last run)
[02:47] <stub> Ok. Nuking the DB fine with you Kinnison? Or is there stuff you can't happily rebuild in there at the moment you need to work with?
[02:47] <stub> jamesh's Bugzilla stuff can be rerun whenever.
[02:47] <Kinnison> you can rebuild, that's fine
[02:48] <kiko> Kinnison, did you note my comment above -- I don't actually think a new gina run is useful..
[02:49] <Kinnison> kiko: in an of itself, probably not, but it'd be good to have a fresh run in order to confirm that nothing's gone wrong with any of the cases not tested during the incremental runs
[02:49] <Kinnison> kiko: Given the run against production will be a fresh run, it's worth it to have one or two full fresh runs between now and production, don't you think?
[02:49] <kiko> Kinnison, yes, that's fine
[02:56] <jordi> SteveA, kiko: will be back
[03:11] <salgado> stub, did we have a production rollout this week already?
[03:11] <stub> salgado: No. Been having bzr problems which have delayed them.
[03:39] <SteveA> back
[04:03] <kiko> bradb, ping?
[04:03] <bradb> kiko: hi
[04:03] <kiko> bradb, remind me how we access the advanced search form at the moment.
[04:04] <bradb> kiko: it's that ugly "Advanced Search (3)" link in the search lists portlet
[04:04] <kiko> bradb, the interesting part is that that portlet is missing from the pages under /people
[04:04] <kiko> so I can't see, for instance, which bugs you have fixed.
[04:05] <kiko> so
[04:05] <bradb> yes, so is the actions portlet
[04:05] <kiko> a) is there a URL hack that can get me there?
[04:05] <bradb> (well, the "Report a Bug" link, in any case)
[04:05] <kiko> b) how should we expose the advanced search link better?
[04:06] <kiko> bradb, why don't you make the link to the advanced search a part of the avanced search macro itself?
[04:06] <bradb> kiko: I can bring the search stuff over into FOAF.
[04:06] <kiko> bradb, there is already searching in FOAF, you realize?
[04:06] <kiko> it's just basic.
[04:06] <bradb> yep
[04:06] <kiko> I was wondering if it wouldn't be better to unify these things and offer both basic and advanced search everywhere we offer searching.
[04:06] <kiko> what do you think?
[04:06] <bradb> yeah, probably
[04:07] <kiko> should I file a bug?
[04:07] <bradb> I still have my malone-search branch, that I started at UBZ, to make this look somewhat better
[04:07] <bradb> kiko: sure
[04:07] <kiko> okay, cool.
[04:11] <kiko> bradb, and as for question a) above?
[04:11] <bradb> kiko: there's no URL that I know of to get you there
[04:11] <kiko> search=Advanced wouldn't work, would it?
[04:12] <salgado> kiko, no, there isn't one. that +bugs-advanced page is not registered under IPerson
[04:13] <kiko> okay.
[04:13] <kiko> bradb, salgado: filed bug 4772.
[04:13] <Ubugtu> Malone bug #477: ftpd (Ubuntu) - Config of pure-ftpd need to be simplified. Fix req. for: pure-ftpd (Ubuntu), Severity: Normal, Assigned to: MOTU, Status: New http://launchpad.net/malone/bugs/477
[04:13] <salgado> I guess it should be easy to do so, but we need to specify that the context is not a bug target, and thus some widgets (like the milestone one) should be hidden
[04:13] <bradb> kiko: thanks
[04:14] <bradb> bug 1234
[04:14] <Ubugtu> Error: I cannot access this bug
[04:14] <kiko> Seveas, what's got into Ubugtu? :)
[04:14] <bradb> bug 3111
[04:14] <Ubugtu> Malone bug #3111: buildd (upstream) - Use gzip python library instead of sys call for compressing buildlogs Fix req. for: launchpad-buildd (upstream), Severity: Normal, Assigned to: Nobody, Status: New http://launchpad.net/malone/bugs/3111
[04:14] <bradb> !?
[04:14] <bradb> bug 4772
[04:14] <Ubugtu> Malone bug #4772: Allow advanced searching in FOAF (and elsewhere) Fix req. for: malone (upstream), Severity: Normal, Assigned to: Nobody, Status: New http://launchpad.net/malone/bugs/4772
[04:14] <bradb> !
[04:15] <Seveas> that's --- odd
[04:15] <ddaa> Hey there. I'd like to know if anybody can point a place when ProductSeriesSet is _actually_ used?
[04:15] <Seveas> bug 4772.
[04:15] <Ubugtu> Malone bug #477: ftpd (Ubuntu) - Config of pure-ftpd need to be simplified. Fix req. for: pure-ftpd (Ubuntu), Severity: Normal, Assigned to: MOTU, Status: New http://launchpad.net/malone/bugs/477
[04:15] <Seveas> it
[04:15] <Seveas> it's the '.'
[04:15] <Seveas> freaky
[04:16] <kiko> you also need to watch out for "," ";" ":" and "?"
[04:16] <bradb> When Regexes Go Bad?
[04:16] <kiko> bug 4772, the bug of doom.
[04:16] <Ubugtu> Malone bug #4772: Allow advanced searching in FOAF (and elsewhere) Fix req. for: malone (upstream), Severity: Normal, Assigned to: Nobody, Status: New http://launchpad.net/malone/bugs/4772
[04:16] <kiko> bug 4772: when good bugs go bad
[04:16] <Ubugtu> Malone bug #4772: Allow advanced searching in FOAF (and elsewhere) Fix req. for: malone (upstream), Severity: Normal, Assigned to: Nobody, Status: New http://launchpad.net/malone/bugs/4772
[04:16] <Seveas> bug 4772. evil.
[04:16] <Ubugtu> Malone bug #477: ftpd (Ubuntu) - Config of pure-ftpd need to be simplified. Fix req. for: pure-ftpd (Ubuntu), Severity: Normal, Assigned to: MOTU, Status: New http://launchpad.net/malone/bugs/477
[04:16] <kiko> what do you mean you haven't fixed bug 4772?
[04:16] <Ubugtu> Malone bug #4772: Allow advanced searching in FOAF (and elsewhere) Fix req. for: malone (upstream), Severity: Normal, Assigned to: Nobody, Status: New http://launchpad.net/malone/bugs/4772
[04:16] <bradb> heh
[04:16] <kiko> I used to like bug 4772; now I hate it.
[04:16] <Ubugtu> Malone bug #4772: Allow advanced searching in FOAF (and elsewhere) Fix req. for: malone (upstream), Severity: Normal, Assigned to: Nobody, Status: New http://launchpad.net/malone/bugs/4772
[04:17] <kiko> okay, only "." seems to be an issue.
[04:17] <Seveas> r"""\b(?P<bz>(((malone|ubuntu|gnome) )?bug|malone|ubuntu|gnome))\b(?:id|ids|#)?\s+(?:id|ids|#)?(?  If you think that you should have this capability, be sure that you are identified before trying again. The 'whoami' command can tell you if you're identified.
[04:19] <ddaa> But my imagination obviously does not go as far as yours.
[04:19] <Seveas> !reload bugzilla
[04:19] <Ubugtu> The operation succeeded.
[04:19] <bradb> Seveas: the [^\.]  seems unnecessary
[04:19] <Seveas> bug 4772. evil.
[04:19] <Ubugtu> Malone bug #4772: Allow advanced searching in FOAF (and elsewhere) Fix req. for: malone (upstream), Severity: Normal, Assigned to: Nobody, Status: New http://launchpad.net/malone/bugs/4772
[04:19] <kiko> brackets and pipes == babes
[04:19] <kiko> thanks Seveas
[04:20] <Seveas> bradb, indeed, but that part of the code isn't mine so I blame me for carelessly copying regexes
[04:20] <bradb> Seveas: Where did you get it from?
[04:21] <Seveas> standard supybot bugzilla plugin
[04:21] <Seveas> I'm still rewriting it - the next version will include malone (and possibly debbugs) support in a less-hackish way and will most likely be included with supybot
[04:22] <bradb> mdz: ping
[04:23] <ddaa> gasp... lifeless to lead the review team...
[04:23] <ddaa> this guy cannot tell pep8 from GCS
[04:25] <kiko> I would rather ddaa lead the review team
[04:25] <ddaa> kiko: I'm just to much of a perfectionist bastard.
[04:26] <ddaa> I'm trying to learn and be more flexible.
[04:26] <kiko> having lifeless lead it will mean that reviewers will start paying a lot more attention to testing, hopefully
[04:26] <sivang> bradb: but pqm is no human :)
[04:26] <ddaa> That would probably be a good thing. But that would probably expose how expensive good test coverage is.
[04:27] <ddaa> Though, I'm all for requiring at least decent test coverage.
[04:27] <kiko> in terms of runtime or developer time?
[04:27] <ddaa> In term of devel time.
[04:28] <ddaa> in term of runtime, it needs not be so expensive, with a good test framework
[04:28] <niemeyer> kiko: Please, not ddaa.. ddaa complained that there were spaces inside a function once.
[04:28] <niemeyer> :-)
[04:28] <ddaa> vertical space
[04:28] <ddaa> it's like comments
[04:29] <ddaa> it's a deodorant
[04:29] <ddaa> if you need blank lines in a method
[04:29] <ddaa> then you probably should be splitting the method in smaller methods
[04:29] <niemeyer> bradb: Vertical white spaces..
[04:29] <kiko> niemeyer, yes, there's "too much whitespace here, let's add a portlet"
[04:29] <SteveA> we need ascii art portlets in our code
[04:29] <ddaa> niemeyer: but I fully accept that this requirement is more of personal preferenc thing
[04:29] <niemeyer> bradb: (like, one empty line between two blocks of code)
[04:30] <ddaa> yet I'd love the review folk to enforce it.
[04:30] <SteveA> PJE used to put whole pages of blank lines between sections of a module
[04:30] <SteveA> i found that very odd
[04:31] <Seveas> If you need people to test the UI, I'd be happy to help out...
[04:31] <ddaa> SteveA: yesterday, lifeless asked me not to call the bazaar scanning daemon bazaard. I'm not sure which one of us was bikeshedding.
[04:32] <SteveA> it needs a "t"
[04:32] <SteveA> baztaard
[04:32] <bradb> http://www.metropolismag.com/cda/story.php?artid=1595
[04:32] <ddaa> dunno, that makes it sound like "mustaard"
[04:32] <bradb> the air conditioner units remind of the portlets, in some senses
[04:33] <bradb> so, basically, i had this view of a typical lp page whose design could overcome the presence of portlets in the way that this building overcomes the presences of air conditioners: http://www.metropolismag.com/cda/popup_image.php?imageid=4837&tablebgcolor=e4e4e4&width=500&height=375
[04:33] <sivang> bazaard :)
[04:34] <bradb> boxes boxes everywhere!
[04:35] <niemeyer> LOL
[04:35] <Seveas> bradb is going nuts :)
[04:41] <bradb> Seveas: Re: testing the UI: we've been fortunate enough to have gathered a huge amount of user input on the UI already. https://wiki.launchpad.canonical.com/DistroTeamOneOnOne
[04:42] <bradb> to the point that the common problem areas are very well known. there's a lot of overlap in terms of what the Ubuntu developers find difficult about Malone, for example.
[04:44] <kiko> bradb, I was about to say exactly that to Seveas
[04:45] <kiko> bradb, could you format your entries in that page to not be inside a big pre block?
[04:45] <bradb> sure
[04:46] <kiko> you appear to have used wiki markup but didn't take advantage of it :)
[04:59] <bradb> kiko: No, I had a big text dump of information, started turning it into something that would make moin happy, and then went "bah, I'll just wrap it in {{{ }}} for now"
[05:01] <stub> Anyone need me before I go to bed?
[05:02] <bradb> stub: any news on that db patch?
[05:02] <niemeyer> stub: Sleep well!
[05:03] <bradb> stub: i.e. PackageBugContacts, .bugcontact, etc.
[05:03] <kiko> heh
[05:04] <stub> bradb: That all looks fine, except it needs comments
[05:05] <bradb> stub: ok
[05:05] <stub> bradb: But there is enough info in the email for me to add them. I'll merge that tomorrow (got stuck with my own branches today :-/ )
[05:05] <bradb> stub: That'd be great. Thanks a lot.
[05:05] <stub> Unless it is urgent, in which case I can give you a patch number and you stick it in one of your own branches
[05:06] <bradb> not urgent
[05:07] <stub> Night!
[05:13] <niemeyer> Half of the methods in database.branch.Branch are like_this, and the other half is likeThat.
[05:13] <niemeyer> Is there a established convention for this?
[05:15] <SteveA> not yet
[05:16] <SteveA> propose a convention for launchpad on the launchpad list
[05:17] <SteveA> personally, i like foo_bar for properties and attributes, and module level functions, and fooBar for methods.  but that's kinda irrational and personal.
[05:19] <niemeyer> FOr launchpad, it may make sense to use foo_bar for methods as well. This is cleaner when using these methods in templates
[05:19] <SteveA> sounds like a good rationale
[05:35] <carlos> jordi, hi, I'm back
[05:35] <carlos> zyga, ping
[05:51] <kiko-fud> niemeyer, I may need some of your time shortly
[05:51] <niemeyer> kiko: Just ping me
[06:03] <niemeyer> This scheme of importing everything e.g under database/ and interfaces/ is quite practical. But I wonder how it hurts startup time and memory consumption.
[06:03] <niemeyer> For the webserver, it doesn't really matter.. but for scripts that startup and die often, it might make a difference.
[06:03] <SteveA> startup time for launchpad -- not at all
[06:03] <SteveA> start up time for scripts, sure
[06:04] <SteveA> but i think a bigger problem for scripts is that the zcml they use reads in more stuff than it needs to
[06:04] <SteveA> we could do better there, and that would make scripts quite a bit faster
[06:04] <niemeyer> Indeed.. just to get utilities, often.
[06:04] <SteveA> utilities and adapters and security
[06:05] <SteveA> i'll be doing some optimisation work there once we've upgraded zope3
[06:05] <SteveA> because there are more facilities to control the loading of zcml in different situations
[06:05] <SteveA> i hacked one such thing for scripts, but i don't want to maintain it
[06:05] <niemeyer> Nice!
[06:06] <zyga> carlos: pong
[06:07] <zyga> carlos: about the api :)
[06:08] <zyga> carlos: just msg me on priv, I'll be looking at the other monitor
[06:09] <niemeyer> kiko: Have you approved my subscription in the launchpad-review list?
[06:09] <kiko> not yet, I haven't gotten to that folder yet
[06:10] <niemeyer> :)
[06:14] <mdz> bradb: pong
[06:15] <mdz> kiko: do we have a new staging archive for comparison?
[06:15] <gneuman> j #async
[06:15] <gneuman> j #launchpad
[06:22] <Kinnison> mdz: I'm waiting on the say-so for me to re-run the publisher
[06:22] <Kinnison> mdz: Dunno when gina will be done
[06:25] <carlos> zyga, ok
[06:26] <kiko> mdz, no, but we will tomorrow. actually.. Kinnison, how about re-running just the publisher?
[06:26] <kiko> mdz, we don't really need a new gina run.
[06:27] <kiko> (though we want to do one to ensure we still work with the current database)
[06:27] <mdz> kiko: we don't?
[06:27] <mdz> kiko: the production archive has changed since the last one
[06:27] <mdz> kiko: unless we stopped updating the local copy, it won't compare correctly anymore
[06:28] <kiko> shucks.
[06:28] <kiko> you're right.
[06:28] <kiko> mdz, but hey, wait.
[06:29] <kiko> mdz, the production archive didn't change for warty and hoary and breezy except for security, I imagine?
[06:29] <kiko> so we can at least ensure that those are 100%
[06:30] <salgado> kiko, what do you think of storing the country/continent relation in a table? (I guess I could use this: http://en.wikipedia.org/wiki/List_of_countries_by_continent_%28data_file%29 )
[06:30] <mdz> kiko: I've forgotten where the most recent set of inconsistencies were
[06:31] <kiko> salgado, for reports? I'm happy with that.
[06:31] <SteveA> salgado: just make it a function, and plug into that it hardcoded into a single python module, perhaps
[06:32] <kiko> SteveA, but.. how do you connect database countries with continents?
[06:32] <SteveA> unless you want it to take part in sql queries...
[06:32] <salgado> yes, for the shipit reports
[06:32] <kiko> are you proposing keeping country names or ids in the file?
[06:33] <SteveA> i guess it will have to be then
[06:33] <kiko> salgado, I think it's strange that you are considering putting the /relation/ in a table
[06:33] <kiko> err
[06:33] <kiko> relationship more properly
[06:33] <kiko> wouldn't country have a continent column
[06:33] <kiko> and we have a continents table?
[06:33] <salgado> I thought of creating a Continent table with the continent names and codes
[06:33] <salgado> and the country table would then have a foreign key to the continent one
[06:34] <kiko> ah
[06:34] <kiko> that makes more sense
[06:34] <SteveA> russia is in europe and asia
[06:34] <kiko> eurasia!
[06:34] <kiko> next!
[06:34] <SteveA> EMEA
[06:34] <SteveA> i hate seeing "emea" in urls and websites
[06:35] <SteveA> especially when a company won't sell me stuff cos I'm not in n. america
[06:35] <SteveA> and i need to use their substandard EMEA site
[06:37] <ddaa> kiko: hey, I'd like to remove the existing ProductSeriesSet, since it appears to be only cruft. The only bit that seems to be functional about it is the redirect from $product/+series to $product. How can I implement that simply?
[06:39] <kiko> you could just register the view on a different content object, I guess
[06:39] <kiko> perhaps on product itself
[06:42] <Kinnison> mdz: publishing run finished
[06:42] <mdz> Kinnison: drescher?
[06:43] <ddaa> kiko: nevermind, that redirect is broken ATM :)
[06:43] <Kinnison> mdz: aye
[06:44] <mdz> Kinnison: output in ~mdz/compare/current
[06:45] <mdz> cat old/*(.) |diffstat
[06:45] <mdz>  - |18234 ++++++++++++++++++++++++++++++---------------------------------------- 1 files changed, 7940 insertions(+), 10294 deletions(-)
[06:45] <mdz> drescher:[~/compare]  cat current/* |diffstat
[06:45] <mdz>  - |43458 +++++++++++++++------------------------------------------------------- 1 files changed, 9914 insertions(+), 33544 deletions(-)
[06:45] <mdz> (surely larger due to no gina run)
[06:45] <kiko> mdz, since we know that dapper and -security is broken, can we just run over the ones we know should be okay?
[06:46] <mdz> dapper isn't even being compared
[06:46] <Kinnison> mdz: - is prod, + is LP?
[06:46] <mdz> is it being imported?
[06:46] <mdz> Kinnison: correct
[06:46] <kiko> okay
[06:46] <kiko> mdz, drop -security then :-/
[06:47] <mdz> drescher:[~/compare/current]  cat warty.* hoary.* breezy.* |diffstat
[06:47] <mdz>  - |14678 +++++++++++++++++++++++++++++++++++----------------------------------- 1 files changed, 7342 insertions(+), 7336 deletions(-)
[06:47] <mdz> that's excluding all pockets
[06:47] <Kinnison> mdz: the numbers are close enough that I think that's almost entirely the source priority and the Task headers being wrong in production
[06:48] <mdz> Kinnison: it's also corrected priorities and sections, so far
[06:48] <mdz> but I can't eyeball a 70k-line diff right now
[06:49] <kiko> I can. mdz, can you mail it to me?
[06:49] <mdz> and if I have to eyeball the whole thing, I want to do it once, for the final production run
[06:49] <mdz> kiko: I thought you had a drescher account now
[06:49] <kiko> oh, I do.
[06:51] <jordi> SteveA: back too.
[06:51] <jordi> I'm going to inclide the changes we've discussed and post a draft in the wiki.
[07:14] <sabdfl> Kinnison: ping
[07:15] <salgado> elmo, pqm strikes again. :-(
[07:16] <bradb> mdz: hi
[07:16] <mdz> bradb: meeting now, what's up?
[07:17] <bradb> mdz: 1. In Bugzilla, presumably "Target Milestone" is the forward looking targeting mechanism, like milestones in malone, right? (Just being paranoid about this to make sure I can tell jamesh how to migrate this data properly. 2. Do you model/track backport fixes in anyway in Bugzilla currently?
[07:17] <kiko> Kinnison, did you update your soyuz production laundry list?
[07:17] <mdz> bradb: 1. yes, 2. not explicitly, though backports bugs do end up there sometimes
[07:18] <bradb> mdz: ok, thanks
[07:18] <mdz> bradb: or do you mean backports as in -updates and -security?
[07:18] <bradb> mdz: backports as in making sure a bug gets fixed in all of warty, hoary, breezy and the current release, for example, and tracking the fix in each of those places.
[07:19] <Kinnison> kiko: oops, not done the wiki page yet
[07:19] <mdz> bradb: ok, that's entirely ad-hoc at the moment (status whiteboard, title, etc.)
[07:19] <Kinnison> kiko: I'll get onto that now
[07:19] <bradb> mdz: ok, that's what i thought, thanks
[07:19] <kiko> thanks Kinnison
[07:22] <Kinnison> kiko: https://wiki.launchpad.canonical.com/SoyuzRunsUbuntuTaskList
[07:22] <Kinnison> kiko: that is a basic dump with a little more info
[07:22] <Kinnison> mdz: ^^
[07:22] <kiko> thanks
[07:30] <kiko> Kinnison, what blocks us running the imports through soyuz right now?
[07:30] <kiko> s/imports/uploads
[07:33] <elmo> Kinnison: you know about the Releases files being wrong on drescher right?
[07:34] <elmo> Kinnison: and that you're providing uncompressed Packages files but shouldn't be?
[07:37] <Kinnison> kiko: the autotest ones, or the dapper ones?
[07:37] <Kinnison> elmo: How are the releases files wrong?
[07:37] <Kinnison> elmo: and I can turn off uncompressed packages files
[07:37] <kiko> Kinnison, the autotest ones would be a beginning :-)
[07:38] <elmo> +Description: Breezy is the third release of Ubuntu. Breezy is due to be released in October 2005.
[07:38] <elmo> in the top level
[07:38] <elmo> +Origin: ubuntu
[07:38] <elmo> +Label: ubuntu
[07:38] <elmo> +Architecture: binary-amd64
[07:39] <elmo> in the per architecture/component
[07:39] <elmo> it should be 'Ubuntu' and 'amd64', not 'binary-amd64'
[07:40] <elmo> +Filename: /srv/launchpad.net/staging-archive/ubuntu/pool/main/l/lvm10/lvm10-udeb_1.0.8-8_i386.udeb
[07:40] <elmo> from ubuntu/dists/breezy/universe/debian-installer/binary-i386/Packages.gz
[07:40] <elmo> is obviously wrong too
[07:42] <Kinnison> elmo: the description comes from the database
[07:43] <Kinnison> elmo: I can capitalise the origin and label, and I'll look into why the binary- isn't being strepped
[07:43] <Kinnison> erm, stripped
[07:43] <Kinnison> as for the filename, I haven't a clue (yet)
[07:44] <kiko> Kinnison, could it be that you need to use the distro title instead of the name?
[07:44] <Kinnison> kiko: It might be
[07:44] <kiko> I am unsure which is correct :-(
[07:47] <Kinnison> elmo: Should Origin be capitalised in the Packages files too?
[07:48] <elmo> err, surely it's obvious what's correct?
[07:48] <elmo> you have a reference implementation
[07:48] <Kinnison> Sorry, that came out bitchy
[07:48] <Kinnison> goddamn I'm tired
[07:49] <elmo> hiccups don't extend to the Release file which is of all about 10 fields being wrong for all suites, all components, all architectures
[07:49] <elmo> well for the record, in my opinion the obviously correct Origin is 'Ubuntu'
[07:49] <kiko> easy to fix too
[07:49] <Kinnison> okay
[07:49] <kiko> so it's no storm in a teacup
[07:50] <Kinnison> so, capitalised in releases, not in Packages
[07:51] <elmo> err?
[07:51] <elmo> it's capitalised in both in archive.u.c?
[07:51] <Kinnison> Oh
[07:53] <kiko> Kinnison, why don't you give me a call in a bit?
[07:53] <kiko> it might be a good break and I wanted to talk to you
[07:53] <kiko> I might entertain you with stories from the boston and nyc underground
[07:56] <Kinnison> kiko: If you want to chat then give me a ring in about 5 minutes. I'm gonna go and grab a pint of water and a biscuit
[07:57] <kiko> yeah, sure
[07:57] <kiko> I miss talking to you
[08:00] <jordi> SteveA: ping
[08:01] <jordi> carlos: ping
[08:09] <jordi> carlos, SteveA: I have published the draft with additions in the wiki
[08:10] <jordi> please have a look at https://wiki.launchpad.canonical.com/RosettaNewImportPolicy to see what's missing
[08:10] <carlos> jordi, pong
[08:10] <carlos> jordi, I need to go out for an hour or so I will give you some input as soon as I'm back. Ok?
[08:11] <jordi> carlos: I'll be leaving soonish too
[08:11] <SteveA> jordi: hi
[08:11] <jordi> but mail/IRC works
[08:11] <carlos> jordi, ok, then I will give you the input by email
[08:11] <jordi> carlos: I'll see if I can have SteveA to look at it :)
[08:12] <carlos> see you later!
[08:12] <jordi> wb SteveA
[08:12] <jordi> laters carlos
[08:12] <jordi> SteveA: ok, I think I added your issues to the doc. Can you go over it now?
[08:12] <SteveA> jordi: i will do shortly
[08:13] <jordi> I probably need to add your img
[08:13] <jordi> but I'm not sure wher.e
[08:13] <jordi> feel free though
[08:27] <jordi> SteveA: tell me when you're ready
[08:27] <jordi> I should go in about 20
[08:33] <elmo> ok, how do I break hardlinks in python?
[08:33] <elmo> apparently open('foo', 'w') doesn't
[08:34] <niemeyer> SteveA: Are you feeling like a reviewer today? :)
[08:34] <kiko> elmo, does open(2) break hardlinks?
[08:35] <ddaa> elmo: as everywhere else, rename and copy back
[08:35] <ddaa> posix does not seem to have any provision for breaking links... which is kind of weird since there's explicit support for creating them.
[08:36] <kiko> or open, read, and write?
[08:36] <ddaa> kiko: if you do that, you need to unlink between the read and the write
[08:37] <kiko> right, I missed the unlink.
[08:37] <ddaa> e.g "cp a b" will _not_ break hardlinks to b.
[08:37] <ddaa> Which is a rock one probably has to trip on.
[08:38] <SteveA> jordi: remind me of the URL please
[08:38] <SteveA> ah got it
[08:38] <jordi> k
[08:38] <kiko> SteveA, mdz, niemeyer: you have mail
[08:38] <jordi> just on time for my workrave :)
[08:39] <kiko> bradb, ping?
[08:39] <mdz> ddaa: the inverse operation is unlink(2) :-P
[08:39] <bradb> kiko: hi
[08:39] <kiko> did you and SteveA reach closure on X-Lauchpad-Bug versus X-Malone-Bug?
[08:39] <SteveA> yes
[08:39] <SteveA> all done
[08:39] <bradb> kiko: it already landed
[08:39] <kiko> I know
[08:39] <kiko> that's not what I asked though :)
[08:40] <ddaa> mdz: that's usually not what one means by "breaking a hardlink" :)
[08:42] <kiko> bradb, so?
[08:42] <bradb> kiko: I don't think it was worth the rename, if that's what you're asking.
[08:42] <SteveA> jordi: very good, and very clear
[08:43] <bradb> kiko: I didn't think it was worth bikeshedding about though.
[08:43] <siretart> are you launchpad devs happy with pyme?
[08:43] <jordi> SteveA: is it?
[08:43] <SteveA> the explanation is clear, so there is no need for the diagram any more.
[08:43] <SteveA> now we just need the suggested email
[08:43] <jordi> SteveA: good. When I read it, I still think it's a bit messy
[08:43] <siretart> I need to do stuff with gnupg in python, and I am looking for an gnupg module for python
[08:43] <jordi> I'll make improvements
[08:43] <SteveA> ok
[08:43] <jordi> SteveA: should mark have a look at this before I post in the list?
[08:43] <jordi> or is it ready to go?
[08:44] <jordi> (it's missing the template, but that's minor and can do it in 10 mins if I get ahold of a keyboard tonight)
[08:44] <SteveA> we're fine.  the other part is, we'll keep to this policy until end of jan, and see if we've missed any upstreams in that time
[08:44] <SteveA> if so, we adjust
[08:44] <jordi> ok
[08:45] <jordi> I will try to keep track of what requests were rejected, if that's what you mean with keeping track
[08:45] <SteveA> there's that internal wiki page for that
[08:45] <jordi> I have a queue of held requests already
[08:45] <jordi> yup
[08:45] <SteveA> also, mention them to me / kiko / carlos
[08:45] <jordi> k. that's the canonical wiki?
[08:46] <SteveA> yes
[08:46] <jordi> ok. I'll try to post today, but not sure if I'll be able. if not, tomorrow morning
[08:46] <SteveA> because i don't want us to look like we're putting any pressure on them calling them "bad projects who don't like rosetta" or that kind of thing
[08:46] <jordi> good night, going for dinner/cinema
[08:46] <jordi> heh, yes
[08:46] <SteveA> of course, we're not doing that, but it would be misinterpreted
[08:47] <jordi> yeah.
[08:47] <jordi> ttyl
[08:47] <kiko> bradb, can you do a quick change to X-Launchpad-Bug: before the next rollout? it's much more appropriate, I just hadn't considered the problem
[08:48] <bradb> kiko: what do you mean "a quick change"? X-Launchpad-Bug has already landed.
[08:49] <kiko> bradb, your commit message and your post above said X-Malone-Bug.
[08:49] <bradb> my post above was referring to X-Launchpad-Bug (i didn't mention X-Malone-Bug)
[08:49] <bradb> and there's a commit message with the X-Launchpad-Bug rename later on
[08:50] <kiko> ah
[08:50] <kiko> sorry, I guess I read too deep. thanks.
[08:50] <bradb> np
[08:53] <bradb> there's another rename coming your way in pqm ;)
[09:09] <ddaa> kiko: feel up for a very quick review?
[09:12] <jordi> that was easy
[09:12] <jordi> gf not at home, I take her laptop :)
[09:12] <LaserJock> is it possible yet to see a list of subscribed bugs on launchpad?
[09:13] <ddaa> LaserJock: you mean the list of bugs you are subscribed to?
[09:13] <sivang> jordi: what kind of a machien does she have?
[09:13] <jordi> sivang: awful laptop, with Windows XP _in Spanish_
[09:13] <jordi> thank god for PuTTY
[09:13] <sivang> jordi: I'm too spoiled to even using PuTTY now :)
[09:13] <LaserJock> ddaa: yes
[09:14] <sivang> jordi: and I really dislike the fact it's doesn't handle UTF nicely when connected from Windows
[09:15] <ddaa> LaserJock: well... that feature seems missing... at least I cannot find it.
[09:15] <jordi> sivang: this is what there is
[09:15] <jordi> I need to use this or watch TV
[09:15] <ddaa> bradb: !
[09:15] <jordi> or just sit and wait
[09:15] <jordi> :)
[09:15] <jordi> what do you mean it doesn't do UTF-8?
[09:15] <jordi> hl
[09:15] <LaserJock> ddaa: when you subscribe to a bug it says something about being able to view it from your launchpad page but I can't find it
[09:16] <ddaa> Well, that feature sure _used_ to be there.
[09:16] <ddaa> The guy to make miserable about malone UI is bradb.
[09:16] <LaserJock> ddaa: hmm, hasn't been for me for like a month
[09:17] <sivang> jordi: ah, then that's heaven , watching TV fries your brain
[09:21] <bradb> LaserJock: Hm, I can't find a bug open on that. I'll open one now. (Quite a few people have asked for it.)
[09:22] <LaserJock> bradb: cool, thanks.
[09:25] <ddaa> hey kiko, want to do an almost trivial review, for a patch consisting entirely of deletions?
[09:26] <bradb> LaserJock: bug 4788. i subscribed you too so you are notified when it's fixed.
[09:26] <Ubugtu> Malone bug #4788: Should be able to see a list of bugs subscribed to Fix req. for: malone (upstream), Severity: Normal, Assigned to: Nobody, Status: New http://launchpad.net/malone/bugs/4788
[09:26] <LaserJock> bradb: very cool
[09:30] <salgado> bradb, LaserJock, the fix for bug 4788 is already in rocketfuel, just waiting for the next rollout
[09:30] <Ubugtu> Malone bug #4788: Should be able to see a list of bugs subscribed to Fix req. for: malone (upstream), Severity: Normal, Assigned to: Brad Bollenbach, Status: Accepted http://launchpad.net/malone/bugs/4788
[09:30] <bradb> salgado: i thought i remembered seeing somebody working on it at UBZ :)
[09:30] <LaserJock> salgado: when would that be?
[09:30] <salgado> bradb, actually, it was matsubara who wrote
[09:31] <bradb> ah
[09:31] <salgado> bradb, and you reviewed the first version. but he had to change lots of stuff because I rewrote all that buglisting pages in foaf
[09:32] <salgado> LaserJock, in one or two days, at most
[09:32] <LaserJock> salgado: oh wow, sweet
[09:33] <bradb> oh, yeah, i remember suggesting a different title for the link
[09:35] <elmo> Kinnison: is there any documentation on how you handle stuff being in different components in different suites but having the same version?
[09:36] <elmo> Kinnison: alternatively, where in the code should I be looking?
[09:38] <jordi> ok
[09:42] <carlos> jordi, I'm back
[09:43] <niemeyer> SteveA: Would you please be able to review the update-branches branch? It contains the bzrsync cronjob we talked about..
[09:43] <bradb> mental note: use +bugs-all when searching for dups, not +bugs.
[09:46] <SteveA> niemeyer: yes i can, but not tonight.  is it on the PendingReviews page?
[09:46] <niemeyer> SteveA: Not yet..
[09:46] <niemeyer> SteveA: Thanks
[09:55] <jordi> carlos: ok
[09:55] <jordi> carlos: SteveA was happy with the doc
[09:55] <jordi> carlos: have a look
[09:55] <jordi> I also replied to barry, about mailman.
[09:55] <jordi> Hopefully he'll join
[09:55] <jordi> and when RMS finds out, it's going to be fun :)
[09:58] <carlos> jordi, ;-)
[10:03] <kiko> jordi? barry?
[10:08] <lifeless> morning
[10:09] <kiko> hey lifeless
[10:09] <lifeless> kiko welcome back
[10:09] <lifeless> how was your break ?
[10:09] <zyga> SteveA: ping
[10:09] <kiko> lifeless, it was quite good, much needed. and how are you doing this week? how's bzr?
[10:10] <lifeless> bzrs good, pqm is in the final stages of moving to balleny, which is [hopefully]  good as its currently backlogged like buggery
[10:10] <lifeless> I'm well ;)
[10:10] <lifeless> starting to lose the weight put on by conference food :)
[10:14] <carlos> jordi, here?
[10:15] <kiko> lifeless, that will be awesome, this move to balleny. I'm amazed you are already pulling it off I thought it was rocket science
[10:16] <lifeless> heh
[10:16] <lifeless> I landed the code last week to drive pqm as though it was on balleny
[10:16] <lifeless> this move should be straight forward
[10:16] <lifeless> and then the next step is the chrooting
[10:17] <lifeless> which funnily enough, pqm already has support for for baz builds ;)
[10:19] <kiko> lifeless, what else is going on?
[10:22] <lifeless> kiko: some test work in the pipeline
[10:22] <lifeless> somewhat blocked on stevea landing a new zope
[10:23] <lifeless> looking in on the distro test related specs as well, finding my feet there
[10:23] <lifeless> lots of stuff as usual ;)
[10:24] <kiko> cool
[10:24] <kiko> Kinnison, I failed to find the time to call you. are you still available?
[10:29] <lifeless> kiko: I'll be starting up the review meetings next week
[10:29] <lifeless> restarting that is
[10:29] <lifeless> kiko: is the current time suitable for you? Steve was mentioning you seem to have some trouble getting to them
[10:30] <kiko> lifeless, nah, it's okay, I was just overworked the weeks coming to UBZ
[10:30] <SteveA> zyga: what's up?
[10:31] <zyga> SteveA: carlos recommended that I ask you about nice xml reader for python
[10:31] <zyga> to read http://l10n-status.gnome.org/translation-status.xml
[10:31] <zyga> a SAX parser will be fine but anything smarter is even more nice
[10:33] <SteveA> zyga: 8MB
[10:33] <SteveA> not small
[10:33] <SteveA> you can try minidom in the std library
[10:33] <zyga> thnx
[10:33] <SteveA> and if that doesn't work because of the amount of data, i'd use sax from the std library, so you can parse and handle it in an event-based way
[10:34] <SteveA> elementtree is supposed to be minimalist and useful
[10:34] <zyga> hmm, just a novice question: std library is installed by default?
[10:34] <SteveA> yes
[10:34] <SteveA> look at the docs at http://docs.python.org/lib/lib.html
[10:34] <SteveA> you get all that by default
[10:35] <zyga> got it
[10:35] <zyga> I was expecting a flat module model
[10:46] <SteveA> although "import this" says "flat is better than nested", there is sometimes too much of a good thing
[10:59] <sivang> SteveA: minidom also does event based parsing, right?
[11:02] <SteveA> no
[11:02] <SteveA> it does dom based parsing
[11:02] <SteveA> well, it depends what your question means, actually
[11:03] <SteveA> minidom is build upon the sax libraries
[11:03] <SteveA> so it uses event based parsing to build up its in-memory DOM representation
[11:04] <sivang> ah then I mistook this with even based parsing which is probably something different. I recalled that when working with minidom, you define callbacks that are triggered based on the parsing that's done, as in the Kant example in DIP
[11:05] <SteveA> that's sax, not DOM
[11:05] <SteveA> in sax, you define handlers for open some element, close some element etc.
[11:05] <SteveA> then use these handlers to build up whatever state you require, and deal with that state accordingly
[11:05] <SteveA> so you can parse the XML as a stream, which is really the only way if you have potentially LOADS of it
[11:06] <SteveA> in the DOM based model, you have a document object model that you deal with, so a collection of nodes in a graph that you can traverse and query.
[11:06] <sivang> right, so I did mistook SAX for dom.
[11:06] <SteveA> there are DOM implementations that load things into memory as needed
[11:06] <SteveA> but they are complex
[11:07] <SteveA> basically, DOM is more abstract, generally easier to work with, but you pay a price
[11:07] <sivang> SteveA: night!
[11:11] <ddaa> lifeless: what would be the entry point to baz2bzr for the cscvs-import driver script?
[11:13] <ddaa> I'm trying to figure out how I should write the bit that tries to pull the existing bzr branch from the SM, and does a from-scratch import if it's not found.
[11:14] <kiko> bradb, note that bug 3322 is currently assigned to matsubara
[11:14] <Ubugtu> Malone bug #3322: It should be possible to indicate a binary package when filing a bug Fix req. for: malone (upstream), Severity: Normal, Assigned to: Diogo Matsubara, Status: Accepted http://launchpad.net/malone/bugs/3322
[11:14] <bradb> kiko: yep. I just wanted it off my untriaged list. :)
[11:14] <kiko> aha :)
[11:14] <kiko> well
[11:15] <mdz> bradb: why does malone mail me copies of my own comments, and can I disable that behaviour?
[11:15] <kiko> to be honest though
[11:15] <kiko> accepted is very dangerous in that sense
[11:15] <ddaa> lifeless: Specifically, I woud like to know which is better for baz2bzr: always get a bzr branch, maybe empty, or let it create the bzr branch for a from-scratch import.
[11:15] <kiko> how do I indicate I'm actively working on X, bradb?
[11:15] <lifeless> ddaa: ESYNTAXERROR
[11:15] <bradb> kiko: you can't. mpt and I have a proposed fix for that
[11:15] <bradb> "Being Fixed"
[11:16] <lifeless> oh, I see. well if its running on bazaar.ubuntu.com like we plan you *dont need to pull anything*
[11:16] <kiko> yet another status, bradb?
[11:16] <ddaa> hu?
[11:16] <lifeless> you are already on the right place with your bzr branch local.
[11:16] <bradb> mdz: there's no way to do that right now, unfortunately. as a workaround, you can filter out all email coming from your address, where the Reply-To has @bugs.launchpad.net in it.
[11:17] <ddaa> ha... I see... I thought the conversion script would run on a separate system. That bazaar.ubuntu.com is only a http and sftp box.
[11:17] <bradb> kiko: yeah
[11:18] <ddaa> The import process is going to be quite expensive, at least at the beginning. I was expecting we'd want to spread the the load on several boxes for the initial import.
[11:18] <ddaa> Which is also consistent with the fact that ATM I only have sftp access to bazaar.ubuntu.com... no shell.
[11:19] <bradb> mdz: On a sort of related note, I've checked in the new X-Launchpad-Bug that will allow you to filter by component as well. If it doesn't get rolled out tomorrow (might not have made the cutoff date we set before rollouts), then should be rolled out by next week.
[11:19] <ddaa> lifeless: did I miss something?
[11:19] <lifeless> ddaa: yes you did.
[11:19] <ddaa> What did I miss?
[11:19] <mdz> bradb: should I file a bug?
[11:19] <mdz> bradb: I have a similar filter in place for bugzilla and will do that for now
[11:20] <lifeless> ddaa: we talked several times about this. Lets run in on bazaar.ubuntu.com. Its easier. It may be expensive but doing one branch at a time with all local IO should be fine.
[11:20] <lifeless> if its not fine we can reenginer to add complexity later but right now its YAGNI
[11:20] <lifeless> and ping elmo for a full login
[11:20] <lifeless> I spoke with him about it at UBZ
[11:21] <bradb> mdz: maybe you could comment on bug 2145 instead?
[11:21] <Ubugtu> Malone bug #2145: jbailey wants to customize the kinds of bugmail that gets sent to him Fix req. for: malone (upstream), Severity: Normal, Assigned to: Brad Bollenbach, Status: Accepted http://launchpad.net/malone/bugs/2145
[11:21] <ddaa> Ok. Do you consider that launchpad.conf integration is YAGNI as well, or is it the Right Way to do it?
[11:21] <lifeless> omg you are insane
[11:21] <bradb> mdz:  or leave as is, if appropriate. or open a new bug. whatever works for you :)
[11:21] <ddaa> I'm just trying to do things properly.
[11:21] <lifeless> this is a once of cron job running for what, a month at most ?
[11:22] <lifeless> I take back the insane bit
[11:22] <lifeless> but seriously. Balance the costs here.
[11:22] <mdz> bradb: I see it as a separate issue; I would never expect my own comments to me mailed to me
[11:22] <lifeless> its being driven on one system by one person for a fixed time period
[11:22] <mdz> bradb: rather than a matter of preference
[11:22] <lifeless> *any* engineering being done should take that into account
[11:22] <lifeless> with very few tags.
[11:23] <ddaa> tags?
[11:23] <lifeless> things-that-make-baz2bzr-slow
[11:23] <bradb> mdz: is it reasonable to assume that no Malone user will want to receive comments they make as bugmail?
[11:24] <lifeless> so what did you plan to put in launchpad.conf ?
[11:24] <ddaa> I used to think that what makes it slow is baz inventory computation and bzr xml processing...
[11:24] <bradb> mdz: for some people, collecting the comments in the inbox can make it easier to follow discussions (particularly given that the web UI doesn't do citation.)
[11:24] <ddaa> So far, I planned to put the arch_root and bazaar_root paths in launchpad.conf.
[11:25] <ddaa> i.e. places where the arch branches are found, and where the bzr branches are pushed.
[11:25] <LarstiQ> mdz: fwiw, I prefer my comments sent back to me
[11:25] <lifeless> ok, I would not bother.
[11:25] <mdz> bradb: comments sent through the web aren't threaded anyway, right?
[11:25] <lifeless> hard code it for bazaar.ubuntu.com/override that in any tests.
[11:25] <mdz> LarstiQ: weirdo ;-)
[11:25] <LarstiQ> mdz: present! ;)
[11:25] <lifeless> because there are no plans to have this operate in different environments, we can refactor later if needed
[11:26] <ddaa> I was planning on testing it end-to-end on my local system. Where the hardcoding would be annoying.
[11:26] <bradb> mdz: it feels like a preference to me, but i'd encourage you to do whatever you want. if you think a separate bug is better, arguing that it shouldn't be configurable, I'D DELETE IT. (just kidding)
[11:27] <lifeless> ddaa: short story, do whatever is *easiest*. Thats the TDD mantra. Don't code something until you are actually using it.
[11:27] <ddaa> ok
[11:27] <lifeless> myself, I would have any end to end tests I need in the code I write
[11:27] <lifeless> because otherwise its hard for anyone else to help you, and hard for you to verify it works
[11:27] <ddaa> right
[11:28] <lifeless> and given I'd be doing that, I'd have (probably) and environment variable to control it, as thats easier than dicking with launchpad.conf in a temp dir from within a running python process to a subprocess
[11:28] <lifeless> like with have one for the database to use
[11:31] <ddaa> Well, if all tests has to be automated, at least one test has to do the subprocess thing.
[11:31] <ddaa> At least to check the zopeless environment initialisation is done properly.
[11:32] <lifeless> right, but the way that it does that is without a fake dir, it just sets an environment variable
[11:33] <ddaa> which fake dir are to talking about?
[11:34] <lifeless> it does not need to write a new launchpad.conf
[11:34] <lifeless> is that a clearer statement
[11:34] <ddaa> Well, I'd expect the default/launchpad.conf would be set properly for tests
[11:34] <lifeless> its not
[11:34] <lifeless> the test suite sets the right one
[11:35] <kiko> really?
[11:35] <kiko> when testing gina I just modified default/launchpad.conf
[11:35] <ddaa> and that the production/launchpad.conf would be the one with the real values
[11:35] <kiko> and it worked (apparently)
[11:35] <lifeless> there is a section in teh default file called 'canonical testrunner'
[11:36] <lifeless> that section is used to connect to the test db
[11:36] <lifeless> but is not used when you do 'make run'
[11:36] <lifeless> cron scripts etc will not use the testrunner config by default, they have to be told to do so when testing
[11:37] <kiko> ddaa, I am in principle fine with the patch at https://chinstrap.ubuntu.com/~dsilvers/paste/fileZOw6UW.html
[11:37] <lifeless> ddaa: there are two local dbs - the one you use interactively and the one used by the test suite.
[11:37] <lifeless> ddaa: default/launchpad.conf points things at the one you use interactively by default
[11:37] <ddaa> sure the lauchpad_ftest
[11:37] <sivang> Night all
[11:37] <kiko> ddaa, I am a bit unhappy it didn't solve the problem I introduced a while back when fixing the sync admin page for you
[11:37] <kiko> ddaa, and I don't quite understand how productseriesset could be so unused
[11:37] <kiko> but r=kiko
[11:37] <ddaa> lifeless: yes, so where is the contradiction with what I said?
[11:38] <lifeless> ddaa: nm, obviously unsynced
[11:38] <ddaa> kiko: AFAICT it became entirely redundant with the arrival of Navigation classes.
[11:38] <kiko> ddaa, perhaps.
[11:39] <ddaa> grepping for it finds nothing, and removing it does not seem break /bazaar or $product/+series/$series pages. And the test suite passes.
[11:39] <kiko> okay, go forth and nuke it
[11:40] <ddaa> kiko: just want you to say r=kiko :)
[11:40] <kiko> I did already :)
[11:41] <ddaa> cool, once it's in the queue, I'll ask you another quick review for the patch that adds a _normal_ ProductSeriesSet.
[11:42] <kiko> okay, nice
[11:43] <kiko> ddaa, do you remember the bug I fixed for you that unbroke /bazaar?
[11:43] <ddaa> kiko: I do not know what the bug actually was
[11:43] <kiko> could you look into that hack and perhaps fix it properly as you are there
[11:44] <ddaa> kiko: I do not know what you are talking about :)
[11:45] <kiko> hmmm
[11:45] <ddaa> I just know that the page stopped working, I filed a bug, and some time later it was working again.
[11:46] <ddaa> Which is about the full extend of my participation with the development of this feature...
[11:46] <kiko> heh
[11:46] <kiko> ok, let me try digging up what I did
[11:50] <ddaa> kiko: here's the next logical step, that actually add code, with tests! https://chinstrap.ubuntu.com/~dsilvers/paste/fileSSVvPf.html
[11:51] <kiko> wow, sweet!
[11:51] <kiko> very nice ddaa
[11:52] <ddaa> there's actually a bug in this code, to see if you are paying attention :)
[11:52] <ddaa> (well, actually, I just saw it...)
[11:53] <kiko> +        return ProductSeries.get(series_id) -- ?
[11:53] <kiko> okay, ProductSeries is defined there
[11:54] <ddaa> """Get a IProductSeries by its database id."""
[11:54] <ddaa> should be "Get a ProductSeries", as it actually implements three different interfaces.