[12:06] <scorpix> when i try to create an Arabic template for Gaim i get this error:  Sorry, you don't have permission to access this page.
[12:08] <scorpix> how can i create a Translation Template for gaim?
[04:17] <spiv> lifeless: canonical.librarian.storage._relFileLocation
[06:09] <stub> lifeless: I have so far been unable to tag sftp://chinstrap.ubuntu.com/home/warthogs/archives/stub/launchpad/production/1.40 as sftp://chinstrap.ubuntu.com/home/warthogs/archives/rocketfuel/launchpad/production/1.40 - I keep getting back the same error "PQM Cannot merge between different VCSsystems."
[08:17] <stub> SteveA, jamesh, spiv: open-id looks like what we want for allowing people to authenticate against Launchpad. It seems complicated enough to support our requirements, and not much more so. I think we should run with this rather than reinvent it badly. It would be good if you can have a look over the specs to double check my opinion when you have time
[08:18] <stub> (this isn't scheduled or assigned yet, so not urgent - just something there are persitant mutterings about)
[08:29] <SteveA> stub: okay.  i'd stay stick the URLs and rationale in a bug or spec, and we'll look at it February earliest
[08:30] <SteveA> no point looking earlier as we have a whole bunch of polish and stability work on launchpad before then
[08:30] <SteveA> if you get me a good URL, i'll take a brief look now
[08:38] <jamesh> SteveA: spec is at http://openid.net/specs.bml, and we have a bug open about it here: https://launchpad.net/products/launchpad/+bug/1169
[08:38] <Ubugtu`> Malone bug #1169: Launchpad should support OpenID Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Nobody, Status: New http://launchpad.net/malone/bugs/1169
[08:39] <jamesh> the spec feels like it would be easier to understand with some more examples and maybe sample code
[08:45] <SteveA> i've read the overview.  so, the idea is that we provide on the launchpad end the facility for anyone to say "I am NAME from Launchpad", and a registry of to which sites Launchpad will say "NAME says you can use Launchpad to authenticate with you"
[08:48] <jamesh> yeah
[08:48] <stub> People say 'I am https://launchpad.net/peope/stub', and other systems can redirect to launchpad, get us to do authentication, and send back a cookie
[08:48] <jamesh> it works by the remote site bouncing the user through the OpenID server's website and back again
[08:49] <stub> erm... I should say token. Cookie has too many meanings
[08:49] <jamesh> so the OpenID server can check the user's credentials (cookies, basic auth, SSL client certs, or whatever else)
[09:10] <SteveA> stub: any items for the meeting agenda today?
[09:10] <stub> Ooh... its thursday.
[09:10] <stub> Erm... just production and staging as normal, following up on my status report to launchpad@
[09:11] <SteveA> i need to look through my summary of the last meeting.  there were some things mentioned there
[09:11] <SteveA> what about a gina run?
[09:11] <SteveA> that still hasn't happened
[09:11] <stub> Nope. People want more runs on staging.
[09:12] <stub> (which has been rebuilding the db for the last 3 hours now - daily syncs no longer look possible.)
[09:16] <SteveA> too much data?
[09:17] <stub> SteveA: Yes - db is growing. Should be fine - I'll just need to schedule a database sync once or twice a week instead of every day. We can keep going with the daily code drops.
[09:19] <SteveA> does syncing take a lot longer than copying the raw data?
[09:22] <carlos> morning
[09:24] <stub> SteveA: Yes - raw data is about 4.5GB. Importing that data into PostgreSQL takes time, and then constraints need to be created and checked, and indexes on that data need to be built.
[09:24] <sivang> morning carlos 
[09:24] <stub> SteveA: We could throw RAM at the problem, but it would only delay the inevitable
[09:24] <stub> carlos: Hi
[09:25] <SteveA> so, you can't just copy the raw database files?
[09:26] <zyga> carlos: morning
[09:26] <zyga> carlos: just pull and have a look
[09:26] <zyga> carlos: it was easier than I really thought
[09:26] <carlos> zyga, you have it already?
[09:26] <carlos> dude you rock...
[09:26] <zyga> no it was just plain easy this time :)
[09:29] <carlos> zyga, I see, you just import all .po and .pot files available, right?
[09:29] <zyga> right
[09:29] <zyga> I think we need a mapping between 'gnome' products and 'our' products
[09:29] <zyga> I don't thing they are 100% identical
[09:30] <carlos> zyga, yeah, I will create a log when I don't create a product in our database
[09:30] <carlos> so we can create or detect that problem
[09:30] <carlos> s/create/create a new product/
[09:30] <zyga> so do I need to add anything now?
[09:31] <carlos> zyga, hmmm, anyway... In the long term, if you were able to use the .xml to filter out obsolete .po and .pot files... sometimes we have such files there
[09:31] <stub> SteveA: No - that would involve shutting down emperor to keep the datafiles clean. And even if we could do it with no downtime (eg. a snapshot capable filesystem on emperor), it isn't exactly supported and would introduce more variables into the staging environment (which would be bad).
[09:31] <SteveA> zyga/carlos: make sure the contributed code has a comment at the top with copyright who wrote it, when, and what the licence is
[09:31] <carlos> zyga, but I think that's enough to start the import
[09:31] <zyga> SteveA: it's there :)
[09:31] <carlos> #!/usr/bin/env python
[09:31] <carlos> # (c) Zygmunt Krynicki 2005,
[09:31] <carlos> # Licensed under LGPL, see COPYING for the whole text
[09:31] <SteveA> stub: i see.  so postgresql doesn't have that facility at this point
[09:31] <zyga> carlos: okay, the XML will be the second shot but we still need language information, xml don't has it
[09:32] <carlos> zyga, don't worry about the language information
[09:32] <carlos> zyga, what I mean is use what you have 
[09:32] <carlos> and the xml to generate a list of products + branches
[09:32] <stub> SteveA: I don't think any DB's do.
[09:32] <carlos> zyga, if a .po or .pot file come from a branch or product that the xml does not have, just ignore it
[09:32] <stub> Well.. maybe some of the toys.
[09:33] <SteveA> stub: FileStorage and DirectoryStorage do ;-)
[09:33] <carlos> zyga, we will care about the languages on import time
[09:35] <carlos> zyga, hmm, also, would be really useful if you would give me another argument that we have available from the .xml file, the path from where the file comes, but that's a plus
[09:35] <zyga> hmm
[09:35] <carlos> zyga, I forgot to comment it to you yesterday
[09:35] <zyga> okay so let's get this straight
[09:36] <zyga> we don't care about languages at all right now, just about products+branches
[09:36] <zyga> and for each p+b you want a path, right?
[09:38] <zyga> carlos: strainght from the XML: module/version/component@dir
[09:39] <carlos> zyga, right
[09:39] <carlos> zyga, if you give me the path + filename, that's enough for me
[09:40] <carlos> as a single argument
[09:40] <zyga> filename? 
[09:40] <zyga> to the pot?
[09:40] <carlos> the filename of the content you give me, like evolution-2.2.pot
[09:40] <carlos> or evolution-2.2.es.pot
[09:40] <carlos> sorry, .po
[09:40] <zyga> module/version/component@dir + module/component/potname@name
[09:41] <carlos> hmmm
[09:41] <zyga> hmm, right now we can just add getURL() to FileToSync
[09:41] <carlos> yeah, for the .pot file that's perfect
[09:41] <zyga> k
[09:41] <carlos> I don't need the URL, just a path to the .pot file
[09:42] <zyga> the path on the server, right?
[09:42] <carlos> and for the .po files the path+ the filename as you have it at l10n-status.gnome.org
[09:42] <zyga> ok
[09:42] <carlos> zyga, the path on the source tree
[09:45] <zyga> carlos: okay just to be sure, the xml has that data in: potfile-in-source-tree: module/version/component/podir@dir + module/version/component/potname@name
[09:46] <zyga> branches+products need to come from the xml while the actuall list of .po's come from index.txt
[09:47] <carlos> zyga, private message so I don't send spam here...
[10:23] <SteveA> spiv: > +    tm = initZopeless(config.builddmaster.dbuser='fiera')
[10:23] <SteveA> does that make sense at all?
[10:23] <SteveA> or is it someone's search-and-replace taken too far?
[10:26] <jamesh> SteveA: it's a syntax error, so it is probably the latter
[10:34] <SteveA> jamesh: so it is.  thanks.
[10:36] <SteveA> jamesh: error reporting looking okay?
[10:37] <jamesh> SteveA: yeah.  I need to write some more tests for it and clean things up
[10:38] <jamesh> SteveA: I've got it writing the reports to files, and showing the error identifier on the error web page
[10:41] <SteveA> that's great
[10:42] <SteveA> i'm looking forward to getting this into production and on staging, as it will make the QA work a lot easier and more effective
[10:43] <SteveA> it will also let users of launchpad know we can find out what went wrong in their particular case in a more straightforward way
[10:43] <SteveA> also, i'll be able to turn off the in process /error pages
[10:44] <jamesh> Do we still want the exceptions sent to the logging framework?
[10:44] <jamesh> (I think the current system does so)
[10:46] <SteveA> yes, at least when running on development boxes
[10:46] <SteveA> no point really when running in production
[10:46] <SteveA> config file setting, perhaps?
[10:46] <jamesh> sounds good
[11:31] <Nafallo> carlos: there? :-)
[11:31] <carlos> Nafallo, hi
[11:32] <Nafallo> carlos: morning. I think we should kill of sv_SE completly. ppl only translates more and more in it as long as it exists.
[11:33] <Nafallo> doable? :-)
[11:33] <carlos> Nafallo, yes, but you need to merge first those translations into 'sv'
[11:34] <carlos> Nafallo, get a .po file, merge it by hand with the one from 'sv'
[11:34] <carlos> and upload the merged one into 'sv'
[11:34] <carlos> then, ping me with the URL of the merged pofiles
[11:34] <carlos> and we will get ride of them
[11:35] <Nafallo> hmm, oki. I'll start with that as soon as time provides then :-)
[11:35] <BjornT> jamesh: ping
[11:36] <carlos> Nafallo, ;-)
[11:39] <jamesh> BjornT: hi
[11:40] <BjornT> jamesh: hi. i'm trying to fix bug 3207, but i fail to create a test case for it
[11:40] <Ubugtu`> Malone bug #3207: line endings must be canonicalised before checking signatures on PGP/MIME messages Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Bjrn Tillenius, Status: Accepted http://launchpad.net/malone/bugs/3207
[11:41] <BjornT> jamesh: do you have any idea how to create an email, signed by sample person, that behaves like the email in that bug?
[11:43] <jamesh> BjornT: Shouldn't be too difficult to do with the email library (/me crosses fingers)
[11:44] <jamesh> create the message part and serialise it with '\r\n' line endings, sign it, and wrap the content and signature in a multipart message, then convert all the line endings back to '\n' (or '\r')
[11:47] <BjornT> jamesh: yeah, i've tried doing like that manually. i'll try again using the email library, though, maybe i missed something
[11:52] <jordi> ok, so it looks very likely that we'll have mailman as an official rosetta product :)
[12:05] <matsubara> good morning
[12:08] <cprov> morning hackers
[12:09] <carlos> jordi, dude, you rock!
[12:09] <carlos> :-)
[12:34] <SteveA> developers meeting in 25 mins
[12:35] <SteveA> any other items for the agenda
[12:38] <kiko> hey there
[12:39] <mpool> hi
[12:39] <kiko> martin!
[12:39] <kiko> how's it going man?
[12:39] <mpool> man
[12:40] <mpool> too slow; too much to do :/
[12:41] <kiko> heya SteveA 
[12:41] <kiko> mpool, how can I help you?
[12:42] <mpool> oh i don't know
[12:42] <kiko> come on
[12:44] <jordi> kiko: barry, you asked last night, is the main author of mailman
[12:45] <jordi> and he's probably jumping onto the Launchpad!
[12:45] <mpool> wow well done
[12:45] <sivang> mpool: Martin! it's been sometime since i last saw you online
[12:46] <kiko> jordi, barry warsaw? I know him
[12:46] <jordi> in person?
[12:46] <jordi> that's awesome
[12:46] <kiko> jordi, so he wants to translate mailman inside rosetta?
[12:46] <kiko> more power to him
[12:46] <jordi> yup
[12:47] <sivang> kiko: yeah, more and more upstream projects to officialize in Rosetta 
[12:47] <sivang> cool
[12:47] <kiko> argh
[12:47] <kiko> I posted to allhands
[12:50] <jordi> now, it's going to be a week of rejections :)
[12:50] <jordi> according to the new policy
[12:52] <carlos> jordi, ;-)
[12:52] <jordi> kiko: http://lists.ubuntu.com/archives/rosetta-users/2005-November/001054.html
[12:52] <jordi> the outstanding issue is how to convert the mail templates to po and viceversa
[12:53] <mpool> sivang: oh, hi
[12:53] <mpool> i have a good photo of you on flickr
[12:54] <sivang> mpool: yeah, I saw it :) good, but chunky :)
[12:54] <sivang> mpool: can I PM you?
[12:54] <mpool> sure
[12:57] <mpool> well, presumably you can
[12:57] <mpool> is it not workiing?
[12:58] <sivang> mpool: let me try again
[12:58] <kiko> morning bradb 
[12:58] <SteveA> meeting in 2
[12:58] <kiko> that's true
[12:58] <sivang> mpool: after meeting then
[12:58] <SteveA> not a bad time for a brief wrist / eyes break
[12:58] <bradb> hey kiko 
[12:59] <SteveA> Welcome to the launchpad developers meeting
[01:00] <kiko> jordi, great set of answers to barry
[01:00] <kiko> congrats
[01:00] <SteveA> who's here today?
[01:00] <ddaa> Bonjour.
[01:00] <kiko> "the world is bright"
[01:00] <jamesh> me
[01:00] <SteveA> sveiki
[01:00] <mpool> me
[01:00] <matsubara> me
[01:00] <salgado> me
[01:00] <bradb> chu l
[01:01] <BjornT> me
[01:01] <carlos> me
[01:01] <stub> yo
[01:01] <SteveA> apologies from: jblack, lifeless, neimeyer, daf, mpt
[01:01] <ddaa> bradb: looks like the encoding bug is gone.
[01:01] <bradb> ddaa: on OS X right now
[01:01] <spiv> me
[01:02] <SteveA> == Agenda ==
[01:02] <SteveA>  * Roll call
[01:02] <SteveA>  * Agenda
[01:02] <SteveA>  * Next meeting
[01:02] <SteveA>  * Activity reports
[01:02] <SteveA>  * Items from last meeting
[01:02] <SteveA>  * Production / staging (stub)
[01:02] <SteveA>  * Production gina run (stub)
[01:02] <SteveA>  * Naming of functions, methods, attributes and properties. (SteveAlexander)
[01:02] <SteveA>  * Launchpad user community meetings. (SteveAlexander)
[01:02] <SteveA>  * A launchpad mailing list for everyone. (SteveAlexander)
[01:02] <SteveA>  * Keep, Bag, Change (Kinnison)
[01:02] <SteveA>  * Three sentences
[01:02] <SteveA> 
[01:02] <SteveA> is Kinnison here?
[01:02] <SteveA>  /msg me any things you want added, although there is quite a bit here
[01:03] <SteveA> okay.  next meeting... 
[01:03] <kiko> I vote for same time same place
[01:03] <SteveA> lifeless asked for it to be earlier.  but, today isn't the best time to discuss it
[01:03] <SteveA> as lifeless and jblack and mpt are not here
[01:03] <SteveA> so, same time next week.
[01:03] <kiko> one hour earlier will be cruel with bradb I suspect
[01:04] <ddaa> Les absents ont toujours tort ;)
[01:04] <SteveA> activity reports:
[01:04] <SteveA> i totally suck.  none since last week.
[01:04] <SteveA> who can claim better than me?
[01:04] <bradb> yeah, 6AM is somewhat harsh for a meeting :)
[01:04] <kiko> I started them today
[01:05] <mpool> i'd like earlier
[01:05] <spiv> I'm up to date since last meeting (although I didn't keep great notes for all days, I sent what I have)
[01:05] <mpool> haven't sent yesterday yet
[01:06] <kiko> gneuman and matsubara are up-to-date (though he sends his to me directly)
[01:06] <SteveA> okay.  send *something* every day.
[01:06] <SteveA> maybe set an alarm for a particular time, like 5pm local
[01:06] <SteveA> and send them each day at that time, when the alarm goes off
[01:07] <SteveA> well done to those who are up to date and have sent several since last week
[01:07] <SteveA> i salute you
[01:07] <SteveA>  - items from last meeting
[01:07] <SteveA> we've covered the agenda items
[01:07] <SteveA> X-Launchpad-Bug was resolved
[01:07] <SteveA> thanks brad
[01:08] <kiko> THANKS bradb 
[01:08] <bradb> np
[01:08] <SteveA> various stuff has happened in the gina department
[01:08] <SteveA> we have a new translation policy
[01:08] <kiko> in the soyuz department better said
[01:08] <SteveA> right
[01:08] <SteveA> so, that's it from last time
[01:08] <kiko> (so major credits to Kinnison and cprov)
[01:08] <SteveA>  * Production / staging (stub)
[01:09] <stub> I failed to do a production rollout this week due to some bzr issues (reported to Robert).
[01:09] <stub> Depending on when things get sorted, I'll either be do a rollout tomorrow and skip next week, or doing the rollout Monday or Tuesday.
[01:09] <stub> I will roll out a two day old HEAD (so what landed yesterday if I get to rollout tomorrow)
[01:09] <stub> Staging had similar issues. The staging database is currently being rebuilt (it is currently in the final stages). I suspect the code update will fail.
[01:09] <stub> Due to size increases with the production database, syncing the staging database to production is now taking several hours so I'll need to cut back database syncs to once per week. Code updates can continue as usual (daily) once we have finished Gina and Publisher testing.
[01:09] <jordi> ffs, sorry. I'm here.
[01:09] <SteveA> hi jordi 
[01:10] <Kinnison> sorry, forgot to start irssi
[01:10] <carlos> stub, so can we assume that staging will be updated once per week starting next week?
[01:10] <jordi> kiko: thanks :)
[01:10] <stub> carlos: The staging *database* will be synced once per week. I think sunday is the best choice.
[01:10] <carlos> stub, will not be stopped by gina or bugzilla migration scripts?
[01:11] <stub> carlos: Yes - depending on the status of Gina and Publisher testing.
[01:11] <kiko> carlos, the gina/bugzilla situation is an interim measure. it's not ideal, but it won't last forever
[01:11] <kiko> as soon as they are run staging can go on doing daily updates
[01:11] <kiko> carlos, can you explain why?
[01:12] <jamesh> I think I only need one more bugzilla import test on staging, so that should get cleared up after the next gina run
[01:12] <carlos> kiko, because the procedure is not yet working as it should so it gives me more control over the process until I can say it's production ready
[01:13] <kiko> okay
[01:13] <stub> carlos: We can arrange a seperate mirror of the production database if staging becomes unsuitable. Let me know. Might need hardware, but I think something can be found short term.
[01:14] <Kinnison> stub: I assume "depending on the status of..." means that for now, we'll do one db sync and then wait
[01:14] <stub> Kinnison: Yes
[01:14] <kiko> stub, are you saying that we should stop syncing daily as our policy?
[01:14] <Kinnison> stub: cool
[01:14] <Kinnison> stub: cool
[01:14] <kiko> I was considering the current situation as temporary
[01:14] <carlos> stub, ok, If i see it'sneeded I will tell you it
[01:14] <stub> kiko: We can still sync daily - it just means that staging will be unavailable for maybe 9 hours each day. Which is silly.
[01:15] <SteveA> we'll be having increasing problems until we get R/O replicas going i think
[01:15] <stub> kiko: Before, it was only taking 1.5 hours which was fine.
[01:15] <kiko> stub, is this database or librarian growth?
[01:15] <stub> kiko: Database. 
[01:15] <Kinnison> stub: is this related mostly to fti?
[01:16] <jamesh> kiko: staging doesn't seem to copy the production librarian files
[01:16] <stub> Kinnison: No
[01:16] <kiko> hmmm.
[01:16] <kiko> stub, if I asked you what's grown so much would you say Rosetta or something else or don't know?
[01:16] <SteveA> an rsync should do for the librarian.  or even something cleverer based on those files that have been added since last time
[01:16] <stub> There is a special hack in the librarian, where it will grab a file from an upstream librarian if the file isn't available locally. Which means we don't have to sync the librarian to staging. (if it is working)
[01:17] <SteveA> oh, i remember Kinnison and cprov doing that, i think
[01:17] <kiko> it's not working, we think
[01:17] <stub> kiko: Staging is a big one.
[01:17] <stub> kiko: Erm.... c/Staging/ShipIt
[01:17] <SteveA> i think we're okay for this week
[01:17] <SteveA> let's move on
[01:18] <SteveA>  * Production gina run (stub)
[01:18] <SteveA> or not stub...
[01:18] <stub> Various people are feeling paranoid, so Gina is not being run on production until she has had more time on staging. If things go smoothly, I suspect we can finally do the production Gina run week after next (which we can confirm next meeting).
[01:18] <SteveA> can someone give a brief summary of where we stand with doing a gina run on production
[01:18] <SteveA> do we need to get elmo to the next meeting?
[01:19] <Kinnison> SteveA: mdz would be of more use
[01:19] <kiko> hmmm
[01:19] <SteveA> mdz will be well asleep
[01:19] <Kinnison> SteveA: but it's a nasty time for him I think
[01:19] <kiko> so the current situation with gina
[01:19] <kiko> we are running comparisons once we have imported and published an archive
[01:19] <SteveA> anyway he can tell folks.  so long as we have a good summary at the next meeting, that's fine
[01:19] <kiko> we believe there are no showstopper gina issues
[01:19] <kiko> there should be no major publisher issues
[01:19] <kiko> but it's a matter now of getting the diffs between archives to a manageable size
[01:20] <kiko> this is made a bit more difficult by the fact that the existing archive had issues
[01:20] <kiko> so we are actually fixing some things in the migration
[01:20] <kiko> I'm responsible for this so I'm probably okay with giving the report on whether it's okay or not (and coordinating with people to find out)
[01:20] <SteveA> ok
[01:20] <SteveA> thanks
[01:20] <SteveA>  * Naming of functions, methods, attributes and properties. (SteveAlexander)
[01:21] <SteveA> there was proposal on the list by niemeyer.  brad supported niemeyer's proposal.
[01:21] <SteveA> i also support niemeyer's proposal.
[01:21] <SteveA> so, now is your last chance to say you totally can't live with...
[01:21] <SteveA> all attributes, properties, methods and functions in launchpad code being of the form foo_bar_baz and not fooBarBaz
[01:22] <kiko> I am in favor of this.
[01:22] <SteveA> except where this is not possible because you're subclassing something that uses a different style, for example
[01:22] <ddaa> Can live with whatever. But I came to prefere the methodName style.
[01:22] <kiko> I am more interested in how we plan to handle a "migration"
[01:22] <SteveA> my personal preference is fooBarBaz for methods, and foo_bar for functions, attributes and properties
[01:23] <ddaa> Also, code that interface with e.g. Twisted will end up as an odd mix of both styles.
[01:23] <SteveA> but it is a more complex rule
[01:23] <SteveA> ddaa: code that interfaces with other systems should use one style consistently
[01:23] <SteveA> so, if we can't use just the launchpad style, then that module / class should use another style
[01:23] <salgado> I'm okay with what niemeyer suggested
[01:23] <stub> except unittest tests, which will generally be test_the_foo_bar_works
[01:24] <SteveA> also, PEP-8 seems to be slightly in favour of foo_bar
[01:24] <ddaa> Well, I like test_ItWorksYeah
[01:24] <ddaa> hu test_itWorksYeah
[01:24] <salgado> but in a database class, the attributes that are in fact database columns will be inconsistent with other attributes
[01:25] <SteveA> they already are.
[01:25] <SteveA> okay.  i didn't hear any serious dissent.
[01:25] <ddaa> Look like quite a few people like the other style, but nobody is willing to argue about it.
[01:25] <SteveA> i'd like to hear one of the following from everyone:  -1 -0 +0 +1.  where -1 means NO WAY, and +1 means PLEASE YES!
[01:25] <stub> salgado: We have decided that database columns should be this_is_a_value too, rather than thisisavalue
[01:25] <SteveA> please say now
[01:25] <stub> salgado: But there will be no mass migration
[01:26] <SteveA> and say quiet otherwise until we're done
[01:26] <Kinnison> -1 (-0 if someone explains the policy for existing code refactoring and it's not insane)
[01:26] <BjornT> -0
[01:26] <jamesh> +1
[01:26] <ddaa> -1 (caps style is faster to type and strains less on the wrists)
[01:26] <bradb> +1
[01:27] <mpool> +0 
[01:27] <cprov> _0
[01:27] <salgado> +1
[01:27] <cprov> +0 ...
[01:27] <carlos> -0
[01:27] <stub> 0 (I can't use a consistant style myself, so am not going to be a hypocrite and pretend I should be listened to on this)
[01:27] <mpool> (i don't really get a vote, but i_like_this())
[01:27] <SteveA> any more for any more...
[01:27] <SteveA> to Kinnison:
[01:27] <sivang> I also don't get to vote, but I tend to follow ddaa on that
[01:27] <SteveA> the policy will be that all new totally new code will be in the new style.
[01:28] <SteveA> where new code touches an existing class or unit of code
[01:28] <SteveA> it should either
[01:28] <SteveA>  - use the existing style (for a small change)
[01:28] <SteveA>  - rework the unit of code to use the new style (for a large change)
[01:28] <Kinnison> Can you define small vs. large changes?
[01:28] <Kinnison> In particular, you could have a massive rework of implementation that doesn't touch interface
[01:28] <SteveA> no.  it's between you and your code reviewer.
[01:28] <Kinnison> is that a small or large change?
[01:29] <SteveA> depends on the nature of the interface
[01:29] <Kinnison> Well, simply based on my dislike of the style chosen, I'm going no higher than -0.5
[01:29] <SteveA> use common sense, and ask the review team for advice
[01:30] <SteveA> we have -1 from ddaa, -1 from sivang (you get to vote, but it might not be totally counted), and -0.5 from Kinnison 
[01:31] <SteveA> everyone else is in favor or can live with it
[01:31] <SteveA> ddaa: can you live with it?
[01:31] <ddaa> Sure, I can live with anything short of rot13.
[01:31] <SteveA> okay.  then it is decided.
[01:31] <SteveA> thanks everyone for keeping this brief.
[01:31] <carlos> SteveA, does it affects current code being reviewed?
[01:31] <SteveA> no
[01:32] <carlos> like my TranslationUploads branch
[01:32] <SteveA> unless you want it to, as a code author
[01:32] <carlos> ok
[01:32] <SteveA> the point is, this should not result in lots of extra work for anyone
[01:32] <SteveA> use that as a guideline
[01:32] <SteveA>  * Launchpad user community meetings. (SteveAlexander)
[01:32] <SteveA> i think we should have meetings that aren't in the strict structure of these developer meetings
[01:33] <SteveA> and invite our user community to participate more
[01:33] <SteveA> including the distro team
[01:34] <SteveA> i'd like some feedback from you as to whether this is a good idea, and i'd like someone other than me to set the first one up
[01:34] <SteveA> the timezone should allow mdz to attend
[01:34] <kiko> I think it's a good idea.
[01:34] <SteveA> and ideally mpt
[01:34] <sivang> very good idea.  I would also have meetings dedicated for walkthrough and guidance for using launcpad for upstream maintainers,
[01:34] <kiko> I can set this up if nobody else isn't interested. mdz and mpt together will be difficult when mpt is back in NZ, though.
[01:35] <SteveA> kiko: thanks.
[01:35] <sivang> we could also invite them and show them the nice features they can use first hand
[01:35] <SteveA>  * A launchpad mailing list for everyone. (SteveAlexander)
[01:35] <SteveA> right now, we use the launchpad list just for development discussions.
[01:35] <SteveA> it doesn't get a lot of traffic usually
[01:35] <SteveA> i think we should open up this list
[01:36] <sivang> but then you risk your list will become loaded with "plain" user traffic like ubuntu-devel has become
[01:37] <sivang> maybe a launchpad-users list? (or is there one already)
[01:37] <SteveA> anyway, we're out of time to discuss this in detail
[01:37] <Kinnison> I think opening up the list will break the launchpad developers' finger-memory
[01:37] <SteveA> so let's talk about it more after this meeting. 
[01:37] <mpool> someone's blog recently had a suggestion that users will always post to the -technical or -devel list, 
[01:37] <Kinnison> and keep the launchpad@ list private
[01:37] <kiko> actually
[01:37] <mpool> because they have a technical question that needs to be answered by developers, right
[01:37] <kiko> there /is/ a launchpad-users
[01:37] <SteveA> later please.
[01:37] <ddaa> I think a separate list would make sense if the devels are required to read it and reply to requests touch their area of ownership.
[01:37] <SteveA> we'll continue right after this meeting
[01:38] <SteveA>  * Keep, Bag, Change (Kinnison)
[01:38] <SteveA> any Keep Bag or Change items?
[01:38] <Kinnison> when I was unwell last week, having the summary was fantastic
[01:38] <SteveA> i will summarize this meeting
[01:38] <SteveA> great
[01:38] <SteveA> 5
[01:38] <SteveA> 4 (to end of KBC)
[01:38] <SteveA> 3
[01:39] <SteveA> 2
[01:39] <SteveA> 1
[01:39] <SteveA> okay. 
[01:39] <kiko> that was stressful.
[01:39] <SteveA> Three sentences.  Drop them into the channel!
[01:39] <stub> DONE: LibrarianGarbageCollection
[01:39] <stub> TODO: Test LibrarianGarbageCollection, PostgreSQL sessions, rollouts
[01:39] <stub> BLOCKED: bzr bugs blocking rollouts
[01:39] <ddaa> DONE: updated TheBazaar, landed Branch support, bzr-based rollout of importd
[01:39] <ddaa> TODO: importd2bzr driver script for baz2bzr. BazaarTaskList.
[01:39] <ddaa> BLOCKED: No.
[01:39] <carlos> DONE: TranslationUploads review, user support, bug triage
[01:39] <bradb> DONE: Lots of bug triaging. Landed X-Launchpad-Bug, bugmail footer. Small UI improvments.
[01:39] <matsubara> DONE: added bugtracker type to bugtracker listing, productseries autogen form.
[01:39] <bradb> TODO: Finish InitialBugContacts. Figure out how to make addNotification + sessions work in tests.
[01:39] <jamesh> DONE: land ValidatingSignOnlyGpgKeys, ErrorReportManagement, some bugzilla-import fixes
[01:39] <bradb> BLOCKED: No.
[01:39] <jamesh> TODO: get ErrorReportManagement tidied up in a reviewable state, do bugzilla milestone migration code
[01:39] <jamesh> BLOCKED: no
[01:39] <matsubara> TODO: finish the productseries bug and fix more bugs
[01:39] <carlos> TODO: Finish TranslationUploads review, bug triage and languagepacks improvements
[01:39] <BjornT> DONE: first cut of ticket-tracker-outgoing-email.almost done with DefaultAffectsTarget. bug fixes. reviews. started specing email for spec tracker.
[01:39] <matsubara> BLOCKED: nope
[01:39] <carlos> BLOCKED: no
[01:39] <BjornT> TODO: finish last bits of DefaultAffectsTarget. clean-up email interface, mainly improving error handling and error messages..refine spec tracker email spec. reviews.
[01:40] <salgado> DONE: Finished rewriting the +packages page, started ShipItReports, code review and random small fixes.
[01:40] <salgado> TODO: Finish ShipItReports, start ProperSignUpWorkflow, code review
[01:40] <salgado> BLOCKED: No
[01:40] <BjornT> BLOCKED: no.
[01:40] <cprov> DONE: package search solution, +builds pages redesign
[01:40] <cprov> TODO: builds/+reset, builds/fmt:icon, unified package search
[01:40] <cprov> BLOCKED: None
[01:40] <gneuman> DONE: fixed and merged trivial bugs
[01:40] <Kinnison> DONE: Was unwell, now working on the ftpmaster tools to let dapper open on soyuz. Doing some publisher fixes elmo brought up in meeting on wednesday
[01:40] <Kinnison> TODO: Finish the tools and fixes, re-run the tests for mdz
[01:40] <Kinnison> BLOCKED: Nothing right now, except bzr sometimes hiccoughing on the launchpad mirror tree.
[01:40] <gneuman> TODO: more fixes and merges
[01:40] <mpool> DONE: various bzr landings and bugfixes, got over jetlag bleh
[01:40] <SteveA> jblack: PAST: drupal, drupal, drupal. Supermirror. Peer programming
[01:40] <SteveA> jblack: FUTURE: minor drupal. Major supermirror.
[01:40] <SteveA> jblack: BLOCKERS: none
[01:40] <SteveA> neimeyer: DONE: Gantry/grumpy planning, small soyuz exploration, branches branch merging, paperwork, cronjobed bzrsync, smart...
[01:40] <SteveA> neimeyer: TODO: Keep working on gantry/grumpy and related
[01:40] <kiko> DONE: holidays! Getting in touch with Soyuz. Various bits of management..
[01:40] <kiko> TODO: Gina production run. Get my life together. Start the launchpad report.
[01:40] <kiko> BLOCKED: partially on Salgado helping me set up a work environment again
[01:40] <gneuman> BLOCKED: no
[01:40] <SteveA> neimeyer: BLOCKED: Not at all
[01:40] <SteveA> lifeless: DONE: split out working tree from branch, partial storage branch preparation for landing, test suite profiling, asterix discussions, various pair programming, catching up with distro testing stuff.
[01:40] <SteveA> lifeless: TODO: pqm to balleny, baz2bzr for importd
[01:40] <SteveA> lifeless: BLOCKED: Zope3 update for test suite patching & hacking
[01:40] <mpool> TODO: bzr speedups, finish and land knits
[01:40] <mpool> BLOCKED: no
[01:41] <jordi> DONE: new import policy; template imports
[01:41] <jordi> TODO: FAQ updates, pending emails, rejections per new policy
[01:41] <SteveA> DONE: moin work, code reviews, management stuff
[01:41] <SteveA> TODO: zope 3 upgrade, moin work, code review, ui infrastructure
[01:41] <SteveA> BLOCKED: no
[01:41] <jordi> BLOCKED: launchpad-experts
[01:42] <jordi> kiko: the experts thing was finished, was it?
[01:42] <kiko> jordi, nope, it's on a branch of mine I looked at yesterday
[01:42] <SteveA> so, other than that, just me blocking lifeless on getting the new zope3 done
[01:43] <sivang> DONE: not yet.
[01:43] <sivang> TODO: Setup rocketfuel, try fix some bugs.
[01:43] <sivang> BLOCKED: Days should have more then mere 24hrs.
[01:43] <SteveA> and various bzr issues slowing people down
[01:43] <SteveA> sivang: you don't need to wait for everyone else.  just fire it into the channel as soon as i announce it
[01:43] <mpool> what are the top bzr blockers?
[01:44] <SteveA> lots of CPU bound activity on updating branches / merging
[01:44] <SteveA> dunno if this is a particular launchpad thing, or if weave stuff could do with some pyrex love
[01:44] <ddaa> inventory xml
[01:44] <SteveA> and it is time to wrap up
[01:45] <SteveA> thanks folks.
[01:45] <SteveA> MEETING ENDS
[01:45] <mpool> well, i'll stay on, anyone who wants can tell me about it
[01:45] <spiv> DONE: Reviews, Supermirror SFTP hacking
[01:45] <mpool> ddaa: what about inventory xml?
[01:45] <spiv> TODO: Supermirror SFTP
[01:45] <SteveA> and now, we can talk about mailing lists
[01:45] <spiv> BLOCKED: no (but still waiting for the insurance claim for the laptop)
[01:45] <SteveA> thanks spiv 
[01:45] <spiv> Sorry all, my DSL died.
[01:45] <ddaa> mpool: isn't that something that causes slowness on larger trees?
[01:45] <SteveA> and also about bzr
[01:45] <kiko> mpool, for the record, I've found my bzr use to be a pleasure, the occasional bug being a lot less painful than tla-spawn
[01:46] <Kinnison> mpool: my major blocker is bzr: ERROR: bzrlib.errors.NoSuchRevision: Branch BzrBranch(u'/home/dsilvers/dev-canonical/rocketfuel-mirror-of-launchpad/launchpad') has no revision pqm@pqm.ubuntu.com-20051122113309-82dcc8325c5c0d19
[01:46] <carlos> hmmm
[01:46] <SteveA> mpool: did you see andrew's activity report about memory failure?
[01:46] <spiv> mpool: I'm very happy that we're using bzr now that I'm temporarily stuck with 256MB of RAM :)
[01:46] <ddaa> personally, I find the lack of shared storage to be very annoying. It's causing branching to be much more expensive than it ought to be.
[01:46] <carlos> sivang, welcome!
[01:46] <stub> mpool: bzr blockers currently are that if I rsync sftp://chinstrap.ubuntu.com/home/warthogs/archives/rocketfuel/launchpad/devel (or another branch), I can't 'bzr revert' in it.
[01:46] <mpool> stub: just heard that one from lifeless, will try to fix it tomorrow
[01:47] <mpool> SteveA: no, what was the memory failure
[01:47] <mpool> Kinnison: can you send me more details?
[01:47] <ddaa> cp branch here, cp branch on chinstrap (to prim rsync), rsync between here to chinstrap, is taking annoyingly long (on the order of half an hour).
[01:47] <stub> mpool: all mine have been sent to lifeless, so he will have probably filtered the wheat from the chaff
[01:47] <SteveA> mpool: half of spiv's memory on his workstation failed.
[01:47] <spiv> mpool: I'm currently working on a desktop PC, because I don't have a laptop.
[01:47] <SteveA> mpool: would have been a disaster before with baz 1.x.  
[01:47] <mpool> ddaa: i *think* inventory xml will not be a killer if you have celementtree, but if it is i'd like to know
[01:47] <ddaa> mpool: that was just hip-shooting.
[01:48] <mpool> ok, so any votes for whether to try to improve network or local speed first?
[01:48] <mpool> sounds like local speed is hurting most?
[01:48] <kiko> I think that's the better plan at the moment mpool 
[01:48] <SteveA> we're dealing with network stuff with rsync at present
[01:48] <kiko> rsync has worked well enough
[01:48] <spiv> mpool: And this PC seems to be rather unhealthy, USB mouse rarely works, PS/2 ports are dead, and can only see 256MB of the RAM it has.  That amount of RAM would be murder with baz 1.x.
[01:48] <stub> mpool: Network is a real pain, but we have workarounds
[01:48] <mpool> well i'm glad it wasn't our fault your ram died
[01:48] <spiv> mpool: :)
[01:48] <Kinnison> mpool: The next time it happens, I'll be sure to
[01:49] <ddaa> in my impression, bzr perform not much better than baz. I was able to optimise the heck out of baz, while bzr just gives what it gives and there's not much I can do about it.
[01:49] <Kinnison> mpool: but I regularly update my mirror, and it seems to come and go
[01:49] <spiv> (This is the best I could assemble from two whole PCs that were working satisfactorily only a few months ago!)
[01:49] <SteveA> ddaa: it is in python.  we can go to C for where it counts
[01:49] <stub> mpool: I'm happy with local speed though personally (it is slow, but not unbearably except when someone lands a few hundred patches on the trunk)
[01:49] <ddaa> SteveA: I'm sure it can do better. Just reporting my personal sentiment as a end user.
[01:50] <spiv> mpool: I am happily *shocked* by the speed whenever I run "bzr annotate" :)
[01:50] <Kinnison> mpool: Also, when merge finds a lot to pull during a single revision, it'd be nice if it gave progress within the revision
[01:50] <mpool> Kinnison: oh, hm, might be a race between rsync downloading and someone else writing; obviously rsync doesn't synchronize
[01:50] <Kinnison> mpool: it's possible I suppose
[01:51] <ddaa> in particular, bzr does not make good use of disk caching, when I commit on one branch, pull in another to rsync from there to chinstrap, and rsync into a third to get updates from chinstrap.
[01:51] <ddaa> I get cold cache performance quite often, while I was able to get hot cache performance most of the time thanks to hardlinking.
[01:52] <mpool> ok
[01:52] <ddaa> which is probably a second-order consequence of the lack of "switch" and bad network throughput, when I think of it.
[01:54] <bradb> mpool: did you end up forwarding my shelve concerns to the list?
[01:55] <mpool> not yet, i will
[01:56] <mpool> ok, well, thanks for the feedback
[01:56] <mpool> even if it stings a little
[01:56] <kiko-afk> :)
[01:56] <mpool> i think we can fix them
[01:57] <carlos> SteveA, kiko-afk I already mailed warthogs mailing list. But I suppose it's better if I tell you it directly, I will be offline for three hours or so after 15:00 UTC today
[01:57] <bradb> mpool: It's good that you're making an effort to stay close to the users. The more user-focussed bzr devs are, the more we will blog about you.
[01:58] <kiko-afk> carlos, it's always better to email us directly if you don't want us to miss it, I filter almost all email
[01:58] <SteveA> bradb: does that principle apply to opening up the launchpad mailing list?
[01:59] <carlos> kiko-afk, ok
[01:59] <bradb> SteveA: Mixing dev and user discussion isn't the best idea, IMHO.
[01:59] <SteveA> i didn't say that
[01:59] <SteveA> we need a place for dev discussions
[01:59] <SteveA> that should be a public place, at least for reading
[01:59] <SteveA> we should have a place for user discussions
[02:00] <SteveA> and someone/some people need to channel information from one place to the other
[02:00] <SteveA> i don't know what a good solution to this is
[02:01] <bradb> When you said "open up" the lp mailing list, I naturally thought you meant allowing anyone to read it and post to it.
[02:01] <mpool> bradb: forwarded
[02:01] <SteveA> bradb: i don't know exactly what i mean ;-0
[02:01] <bradb> A launchpad-users list seems like an obvious idea, to me. (i.e. an l-u that is actually publicized and used)
[02:02] <SteveA> i'd rather have launchpad for users and launchpad-dev for developers
[02:02] <Kinnison> SteveA: You'll break developers' finger-memory
[02:02] <SteveA> it's okay
[02:02] <SteveA> for things to go to the wrong place for a while
[02:03] <bradb> mpool: thanks
[02:03] <Kinnison> SteveA: will developers be required to be on launchpad@ if the dev list becomes launchpad-dev@
[02:03] <Kinnison> and will launchpad-dev@ be private?
[02:03] <SteveA> read-only to most people
[02:03] <SteveA> if such a thing is possible
[02:04] <Kinnison> And private/sensitive mails?
[02:04] <bradb> SteveA: I think that's just a matter of making the list members-only + moderated memberships.
[02:04] <ddaa> I think it's good to have devels keep sending traffic to the users mailing list at first.
[02:04] <bradb> hm, yeah, a "read-only" membership. hm hm.
[02:04] <SteveA> we don't have a -dev irc channel
[02:05] <SteveA> and it isn't a problem
[02:05] <ddaa> It will help "prime the pump". And if user traffic becomes a problem devel will naturally migrate to the other mailing list.
[02:06] <Kinnison> SteveA: No, but we are careful to use a private nopaste service
[02:11] <siretart> spiv: hi. do you remember me? I requested from you that the gpg fingerprint of teams are listed in the .../+rdf output. whats the status about this?
[02:11] <spiv> siretart: Yep, I remember.
[02:11] <siretart> :)
[02:12] <spiv> siretart: The code is mostly written, just needs a bit of tidying.  My laptop being stolen interrupted my work on it, and I never got back to finishing that last 10%.  Thanks for the reminder :)
[02:13] <siretart> spiv: I'm sorry to hear about your laptop :(
[02:14] <spiv> At least it made my luggage a little lighter for the trip back from Montreal ;)
[02:41] <sivang> spiv: lol
[02:49] <BjornT> any reviewer available for reviewing a 120-line (mostly tests) diff? (fix of bug 3207)
[02:49] <Ubugtu`> Malone bug #3207: line endings must be canonicalised before checking signatures on PGP/MIME messages Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Bjrn Tillenius, Status: Accepted http://launchpad.net/malone/bugs/3207
[02:53] <kiko-afk> BjornT, yes.
[02:56] <BjornT> kiko-afk: thanks, i'll send it to you.
[03:00] <BjornT> kiko-afk: sent
[03:03] <SteveA> thanks kiko
[03:07] <kiko-afk> stub, salgado: have 5 minutes?
[03:08] <stub> kiko-afk: sure
[03:08] <salgado> yep
[03:08] <kiko> stub, salgado: some users have complained that we disclose their email addresses
[03:08] <kiko> there's also a bug open on this topic (IIRC)
[03:08] <kiko> I am answering a user's email right now about this
[03:08] <salgado> more than one, IIRC
[03:09] <kiko> but I'd like to see if we can come up with a plan
[03:09] <kiko> so far the suggestion I have is
[03:09] <kiko> allow the user to hide his address, optionally
[03:09] <kiko> tell him that by default his email will be publically visible
[03:10] <SteveA> to launchpad members...
[03:10] <kiko> when the user's address is hidden, don't display his email
[03:10] <kiko> yes, to launchpad users
[03:10] <SteveA> do people need to opt in to get an @ubuntu.com mail address?
[03:10] <SteveA> or does it happen automatically when they get a prefered address?
[03:10] <kiko> I thought that was only for "special people"
[03:10] <salgado> me too
[03:10] <stub> SteveA: It is automatic apon signing the CoC at the moment
[03:10] <SteveA>  @ubuntu.com addresses are basically public
[03:11] <SteveA> you just need the launchpad name, and stick @ubuntu.com on the end
[03:11] <kiko> stub, SteveA: I think @ubuntu.com is small enough to not warrant special-treatment at this time
[03:11] <kiko> only a hundred CoCs have been signed
[03:11] <SteveA> agreed
[03:11] <kiko> a hundred or so
[03:11] <kiko> (~150 IIRC)
[03:11] <kiko> anyway
[03:11] <kiko> do you guys have opinions? what about my strawman proposal? how hard does it sound?
[03:11] <stub> 650
[03:12] <kiko> really?
[03:12] <stub> Well..643
[03:12] <kiko> I need to talk to mako
[03:12] <kiko> he owes me something!
[03:12] <SteveA> to do with his CoC ?
[03:12] <kiko> he said.. well, it's not important right now
[03:12] <kiko> back on track
[03:13] <kiko> I suggest assuming that @ubuntu.com people are SOL for the moment wrt people guessing their addresses
[03:13] <SteveA> fine, for now
[03:13] <kiko> I don't know where we tell them they have @ubuntu.com addresses or I would suggest adding some text there talking about this
[03:13] <kiko> anyway
[03:13] <SteveA> okay, so the proposal is: email addresses are visible to launchpad users by default
[03:13] <stub> Sounds fine. Just replace the emailaddress portlet with a '<blink>Hidden</blink>' message if they set an option.
[03:13] <SteveA> and people are clearly told this on joining
[03:14] <SteveA> and offered an option on their own page to make the email address hidden in the UI
[03:14] <SteveA> except to themselves on the edit email page
[03:14] <stub> It will still be possible to mine email addresses using the peopleselector widget thingy, but that shouldn't cause screaming
[03:14] <kiko> that's my proposal
[03:14] <kiko> stub, really?
[03:14] <SteveA> we should turn that off too
[03:14] <stub> kiko: Sure. Someone changed the token used by the Person vocabulary to be the primary email address instead of the Person.name
[03:15] <LarstiQ> stub: are you sure about the automatic @ubuntu.com? I signed the CoC available via launchpad, but I'm not aware of an @ubuntu.com adress
[03:15] <kiko> stub, "token"?
[03:15] <salgado> stub, and this change caused quite a few regressions
[03:15] <SteveA> (OT: is an @ubuntu.com address included in that widget's data, for people who signed the CoC?)
[03:15] <kiko> (no)
[03:15] <stub> LarstiQ: Try it and see - I believe it will work unless you set your name to something like 'root' or 'postmaster'
[03:15] <salgado> kiko, the token is what is displayed in the widget. the thing that identifies the person
[03:16] <LarstiQ> stub: I just tried, Recipient address rejected: User unknown in virtual alias table
[03:16] <kiko> salgado, why not use the display name?
[03:16] <SteveA> LarstiQ: what's your launchpad homepage?
[03:16] <salgado> kiko, because that has to be unique
[03:16] <stub> elmo would be the only person who knows for sure about @ubuntu.com email addresses and how often they are regenerated
[03:16] <kiko> salgado, what is /displayed/ has to be unique
[03:16] <LarstiQ> SteveA: https://launchpad.net/people/larstiq/
[03:16] <kiko> -- ?
[03:16] <SteveA> salgado: why not use the launchpad name?
[03:16] <salgado> kiko, it used to be the name, but bradb changed it to be the email addres
[03:16] <salgado> s
[03:17] <kiko> salgado, I thought we could use the lp name as a token and display the display name. why can't we?
[03:17] <kiko> bradb?
[03:17] <salgado> kiko, we discussed this quite a few times. I said I was in favour of keeping the name
[03:17] <salgado> 3 months ago or so
[03:18] <SteveA> LarstiQ: yep, bounces :-(
[03:18] <stub> That can be done seperate to this discussion anyway - first step is to stop advertising email addresses for our tin hat wearing comrades. We can follow up with defences against mining email addresses using the search forms or calculating @ubuntu.com email addresses later.
[03:19] <salgado> kiko, in the popup window we display the email address and browsername. but then, when you choose one, we have to store something that's unique. and right now that's the email address
[03:19] <LarstiQ> SteveA: up to a couple of minutes ago I didn't know I could have that address, so I'm not terribly disappointed ;)
[03:19] <SteveA> salgado, bradb: that should be the person.name, not the email address.
[03:20] <kiko> agreed with SteveA, but I believe bradb had a reason for it
[03:20] <stub> It was originally
[03:20] <salgado> SteveA, bradb had a good argument (I think) that for malone users, it's easier to remember people's email addresses than launchpad names
[03:20] <kiko> but wait
[03:20] <SteveA> so
[03:20] <salgado> so I could, when assigning a bug to someone, simply type his email address and submit
[03:20] <SteveA> what has this to do with anything?
[03:20] <kiko> it should be okay to /type in an email address/
[03:21] <kiko> but why use the address as a /key/
[03:21] <kiko> that's what we are discussing
[03:21] <stub> The key is the only thing people have from differentiating 'John Smith' from another 'John Smith'. They probably both have similar Person.names.
[03:22] <SteveA> if i type in stevea, the widget should use stevea as a key
[03:22] <stub> But if you use the email address, it becomes more likely that the token can be used to select the correct 'John Smith'
[03:22] <SteveA> if i type in steve@ubuntu.com then that can be the key
[03:22] <SteveA> and if i select a name from the list
[03:22] <SteveA> then the name should be the key, even if email addresses are presented
[03:22] <SteveA> and, if someone's email address is private, then their email address should not be available for selection
[03:23] <SteveA> only their name.  it should be as if their email address is not in the system
[03:23] <SteveA> from that point of view
[03:24] <Kinnison> SteveA: that's really annoying if you know someone's address but they mark it as private
[03:24] <stub> Or we can leave it the way it is, because I really don't think it is a big issue. We can revisit if people feel that their privacy is being breached.
[03:24] <kiko> stub, yeah, I guess
[03:24] <SteveA> Kinnison: that is their choice.
[03:24] <stub> But exposing them through the search form is much more benign that advertising them to the world.
[03:24] <Kinnison> SteveA: consider if I mark all my email addresses as private
[03:24] <Kinnison> SteveA: Now you can't easily assign bugs to me unless you know my LP user is 'dsilvers'
[03:25] <SteveA> Kinnison: would you be upset if someone wrote a bot that looks up lp user names in the choice widget, and harvested your email address from there?
[03:25] <SteveA> stub: agreed.  i think this will make kiko's email correspondents feel better.
[03:25] <Kinnison> SteveA: Given how used to receiving spam I am, I wouldn't be desperately upset, no
[03:25] <SteveA> and give them tangible benefits
[03:26] <kiko> okay.
[03:26] <Kinnison> SteveA: but making sure whenever we render email addresses in the UI we obfuscate them hard to prevent easy screenscraping woudl be nice
[03:26] <salgado> this is another question. should people say what email addresseses they want visible or not? I was assuming that they could only choose between all email addresses bein public or all not public
[03:26] <kiko> salgado, that should be enough.
[03:26] <SteveA> Kinnison: then why would you mark your email addresses as private in the first place?  is there anothe reason that anti-spamming?
[03:26] <Kinnison> SteveA: I suppose if I disliked receiving email
[03:26] <Kinnison> SteveA: but tbh. I think hiding them from all but registered users is enough
[03:26] <Kinnison> So if a user is not logged in, no email addresses
[03:26] <salgado> this is how it works now
[03:27] <kiko> Kinnison, that's how it works now
[03:27] <kiko> but people freak out
[03:27] <Kinnison> aye, and I think it's enough
[03:27] <salgado> if you're not logged in you won't see a thing
[03:27] <SteveA> so, the proposal is to have three states:
[03:27] <SteveA>  - default: people who are logged in can see your addresses
[03:27] <stub> Email addresses are obfuscated and only available to logged in people already . We are already anti-scraper enough that spammers will pick easier targets. Complaints are from the paranoid and privacy nuts.
[03:27] <SteveA>  - special privacy: no one can see your addresses on launchpad pages
[03:28] <SteveA> kiko: was your original complaint that the address was made public without due notice that it would be so?
[03:28] <LarstiQ> stub: I'm amazed at how much work spammers do to get around things like that
[03:28] <SteveA> kiko: in other words, was it the broken expectation?
[03:28] <kiko> SteveA, no, the guy said "DELETE MY ACCOUNT"
[03:29] <stub> LarstiQ: Are you quoting from first hand knowledge, or propagating myths?
[03:29] <SteveA> i wonder if that was from being offended that the expectation was broken
[03:29] <kiko> be nice stub 
[03:29] <SteveA> or if the user had been given a clear notice on the registration page
[03:29] <kiko> SteveA, no, he said he didn't want his email advertised. I have since written back to him telling him a bit more about the situation, let's see what he says
[03:29] <SteveA> if they would have simply not joined
[03:29] <kiko> I don't know enough to answer that accurately
[03:30] <salgado> for the record, email addresses of automatically created accounts are never displayed because they're not validated
[03:30] <stub> Sorry if that sounded abrupt - I've seen a lot of stuff people talk about as possible which gets passed on as factual.
[03:30] <stub> And I'm genuinly interested if I'm a victim of the fud in that I'm discounting stuff that is real
[03:31] <LarstiQ> stub: quoting from jblack
[03:32] <stub> Ta. He might be talking about wiki scraping, which I believe because one automated solution would target lots of sites.
[03:32] <LarstiQ> stub: who turned out to work for a spammer 1 week
[03:32] <kiko> salgado, you said there were 3 states. were there actually only 2 states?
[03:33] <salgado> not me
[03:33] <kiko> SteveA, blundering xchat completion.
[03:33] <salgado> I'm expecting for the thrid one too
[03:34] <SteveA>  - you have no validated addresses
[03:34] <stub> new, validated, preferred, old
[03:35] <kiko> boguser
[03:35] <salgado> old is not used right now, AFAIK
[03:35] <LarstiQ> stub: you'll have to talk to jblack for more details, I only know it involved building regexes to get around simple obfuscations
[03:36] <kiko> salgado, does SteveA's first two states and the proposed plan sound good?
[03:36] <Kinnison> Given the large amount of noise, I'm still unsure as to what happens when you decide to be super-secretive
[03:36] <stub> LarstiQ: I will. I can believe deobfuscators, authenticating to common software and specifically targetting large sites like live journal. I'm interested in if spammers can be bothered with targetting smaller special cases like 'launchpad' or 'sourceforge'.
[03:37] <kiko> Kinnison, your email addresses will not be disclosed to anyone in the email portlet (and anywhere else we discover we are blatantly disclosing email addresses, which I don't believe exist beyond the selecter widget) 
[03:37] <salgado> kiko, yep. would it be better to have this summarized and sent to launchpad@ or just a bug report is okay?
[03:38] <kiko> salgado, I think you can just use https://launchpad.net/products/launchpad/+bug/1360 for that.
[03:38] <Ubugtu`> Malone bug #1360: Inappropriate display of personal data Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Nobody, Status: New http://launchpad.net/malone/bugs/1360
[03:38] <Kinnison> kiko: but it will still work if I know someone's address when (for example) assigning a bug to them?
[03:38] <kiko> Kinnison, yes.
[03:38] <Kinnison> kiko: okay, then that gets +1 from me
[03:38] <kiko> this has nothing to do with /accepting/ email as input
[03:39] <kiko> only with disclosing email
[03:39] <kiko> or at least that much should be the case -- right salgado, stub, SteveA?
[03:40] <niemeyer> Hey hey.. afternoon folks
[03:40] <kiko> hey niemeyer 
[03:41] <salgado> kiko, yes
[03:42] <kiko> cool.
[03:42] <salgado> although I think this is not going to be so easy to implement
[03:43] <stub> What was the proposed implementation?
[03:43] <kiko> salgado, I thought it would be: column in person table. condition in template. update schema for edit user form. is it harder?
[03:44] <salgado> need changes in the vocabs and the assignee widget, at least
[03:44] <stub> That sounds like stage 2, which may not actually be necessary
[03:44] <kiko> salgado, let's leave the vocabs changes for later.
[03:44] <kiko> does that make it easier?
[03:45] <salgado> sure
[03:47] <Kinnison> use the sodding list
[03:48] <kiko> use the D key
[03:48] <Kinnison> I use a vfolder which combines all my unread mail
[03:49] <Kinnison> but please trim the CC line when it's not obvious that the recipient should be on it
[03:49] <kiko> sorry about that. I just get too much email to be able to reliably trim addresses.
[03:49] <carlos> see you later!
[03:49] <Kinnison> kiko: and every time I get CCed when I really shouldn't have been it makes it harder for me to see my important mail too -- a problem I'm sure you appreciate
[03:50] <kiko> I do, but I can't promise I can do much better. maybe you can use formail to filter out dupes?
[03:50] <kiko> mailman could check if someone was on the CC: list and not send email to them
[03:51] <kiko> that could be a feature
[03:51] <Kinnison> kiko: if you work out how to use formail to ensure the copy I *want*, not the first sodding copy, goes into the right box, I'd be happy
[03:51] <Kinnison> kiko: NO
[03:51] <Kinnison> kiko: I want the sodding mail in the mailing list folder
[03:51] <Kinnison> not in my INBOX
[03:51] <kiko> jesus
[03:51] <Kinnison> INBOX is for mail someone sends *TO* me
[03:51] <Kinnison> I.E. which requires my attention
[03:51] <Kinnison> mailing lists are for conversations I'm party to, but not necessarily instrumental in
[03:52] <Kinnison> perhaps I'm strange
[03:52] <Kinnison> perhaps I'm wrong
[03:52] <Kinnison> but I am me
[03:52] <LarstiQ> Kinnison: mailman actually does (can do) something like this
[03:52] <LarstiQ> ehm
[03:52] <LarstiQ> s/Kinnion/kiko/
[03:52] <bradb> salgado, SteveA, kiko: back. I might be missing some context to give you a useful answer, but the person can be the .name or the email address
[03:53] <LarstiQ> kiko: And I miss out on the conversation because I'm watching the mailing list
[03:53] <Kinnison> LarstiQ: I have a horrible feeling the bzr-devel list does it
[03:53] <bradb> the email address is always shown if there is one, otherwise .name
[03:53] <Kinnison> LarstiQ: I often find mails in my INBOX where they should have been on that list
[03:53] <Kinnison> LarstiQ: which causes me a large amount of grief
[03:53] <Kinnison> LarstiQ: and confusion, when someone replies on list
[03:54] <kiko> bradb, okay. hmmm. I guess it might not be that hard to also use name if the person has chosen not to disclose his email addresses
[03:54] <salgado> bradb, most of the people vocabs include only people with a preferred email address (and teams)
[03:54] <LarstiQ> Kinnison: I think it is possible to turn that off
[03:54] <bradb> salgado: after the bugzilla import is done, i expect there to be a lot of assignees that don't have preferredemails set
[03:55] <salgado> bradb, and the assignee widget knows how to handle that?
[03:55] <bradb> yeah, it should
[03:56] <stub> Staging database has been resynced to production. I'll try a manual code update since the bzr bug is biting.
[04:18] <stub> staging should be up again in about 30/40 mins
[04:21] <kiko> rock on stub
[04:26] <kiko> salgado, how does https://launchpad.net/products/launchpad/+bug/1488 look to you?
[04:26] <Ubugtu`> Malone bug #1488: Launchpad IDs don't work to log in Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Steve Alexander, Status: New http://launchpad.net/malone/bugs/1488
[04:28] <salgado> kiko, easy to implement, I guess. (Is this what you ask?)
[05:02] <jordi> hmm
[05:02] <jordi> carlos
[05:02] <jordi> oh, he left
[05:02] <stub> Yay. The front page on staging is broken again. Stoopid people statistics.
[05:03] <jordi> I win!
[05:03] <stub> Works fine once query has been executed manually and the db is prime, but is dangerous :-/
[05:03] <jordi> woa
[05:03] <jordi> I don't lead anymore!
[05:03] <jordi> wtf
[05:17] <stub> salgado: Did you ever track down what was doing """SELECT COUNT(*) FROM Person, EmailAddress WHERE Person.teamowner IS NULL AND Person.merged IS NULL AND EmailAddress.person = Person.id AND EmailAddress.status = 4""" on the front page?
[05:20] <salgado> stub, one second, I think I know what it is, but I'll make sure
[05:22] <salgado> stub, it's issued because we use a tal:repeat="person view/topPeople"
[05:22] <salgado> stub, although the topPeople() method has a "LIMIT 5" in the query, whenever you do a list(view.topPeople()) you'll get that COUNT query issued
[05:23] <salgado> the problem is that using tal:repeat shouldn't do a list(view.topPeople()), but it does
[05:24] <salgado> I mailed SteveA some time ago on how to reproduce this
[05:25] <salgado> SteveA, have you fixed this already?
[05:26] <stub> salgado: Do you remember if there is a bug on this?
[05:27] <salgado> no, I don't think there is one
[05:28] <stub> salgado: Can you please create one?
[05:29] <stub> I am confused as to why list(topPeople()) would be able to execute the query without the LIMIT 5, as it means the list will be allocated with 153,000 odd spaces but only 5 used.
[05:30] <stub> Ohhh... because that is done using [:5]  somewhere?
[05:30] <salgado> yes. inside topPeople()
[05:31] <stub> So why does list(topPeople()) execute the COUNT(*)?
[05:34] <salgado> AFAIK, sqlobject does that for any query, using only the WHERE clause in the COUNT(*)
[05:34] <salgado> I mean, whenever you do a list(query)
[05:35] <stub> So a fix would be to make topPeople do "        return list(self.getAllValidPersons(orderBy=['-karma', '-id'] )[:5] )", which means it will not be returning a result set, so the COUNT(*) will never be called.
[05:35] <stub> Which won't fix all cases, but should fix this one.
[05:36] <stub> oh... ignore me.
[05:36] <salgado> well, the list(self.getAllValidPersons(orderBy=['-karma', '-id'] ) will issue that COUNT(*)
[05:37] <stub> So it is looking like an SQLObject bug to me
[05:37] <stub> That just happens to be triggered by tal. I don't think tal is broken by doing list(), as if you are ever repeating over a non-trivial sequence your UI is broken.
[05:38] <salgado> I think so. but I think it's also a bug in zope, because I don't want it to call list() on things I want to iterate
[05:44] <stub> kiko-fud: I've kicked off a fresh Gina run - gina.sh as usual, and  logs in the usual place.
[05:46] <kiko-fud> thanks stub 
[05:47] <kiko-fud> stub, this is using rocketfuel tip, I assume?
[05:57] <stub> kiko-fud: Yes
[05:57] <kiko-fud> thanks.
[06:04] <kiko-fud> Kinnison, how about we have that phone chat we were going to have yesterday, now?
[06:09] <stub> Is there a [@TIME@]  in wiki?
[06:10] <stub> Something that gives a UTC time stamp
[06:10] <kiko> umm yes IIRC, look at PendingReviews
[06:11] <stub> That is using @DATE@
[06:11] <stub> Not important
[06:24] <maxx_730> Hey
[06:24] <maxx_730> Someone else have a problem with filing a bug
[06:24] <maxx_730> Complaining about " You must choose a component to file this bug in. If necessary, just guess."
[06:25] <maxx_730> Even though i've already entered it?
[06:30] <bradb> maxx_730: Are you talking about bugzilla?
[06:31] <maxx_730> Yes
[06:31] <maxx_730> I just tried with opera
[06:31] <maxx_730> no luck too :-(
[06:32] <bradb> maxx_730: maybe kiko has an idea. otherwise the right people to ask are probably in #ubuntu.
[06:32] <maxx_730> Ok
[06:32] <maxx_730> I'll try
[06:32] <kiko> I'm on the phone, one moment
[06:40] <bradb> stub: I saw that the db patch landed. Thanks a million.
[06:40] <bradb> maxx_730: Did you manage to get a helpful answer to your question?
[06:47] <Kinnison> kiko: thanks for that call
[06:47] <Kinnison> ciau all
[06:47] <kiko> thanks to you
[06:56] <maxx_730> badb: No, still not working
[06:57] <maxx_730> I want to submit bugs, but it just doesn't work
[07:14] <kiko> sucks to be me
[07:14] <kiko> k-lined on the fast lane
[07:20] <kiko> mdz, Kinnison and I spent some time on the phone today
[07:20] <kiko> when you have a moment I'd like to see if you can help us out
[07:26] <mdz> kiko-afk: give me a call whenever you're ready
[07:26] <kiko-afk> okay, cool
[08:08] <carlos> hi
[08:09] <kiko> hi dude
[08:15] <Alinux> hi carlos :)
[08:25] <ddaa> good night guys
[08:31] <zyga> calos: sorry, nothing new on our front today
[08:32] <zyga> carlos: but instead the desktop team has something neet to show
[08:32] <carlos> zyga, no worries
[08:32] <carlos> zyga, what ?
[08:32] <zyga> www.suxx.pl/blog, first note
[08:34] <carlos> zyga, wow
[08:34] <zyga> a deb is around to try :)
[08:34] <carlos> zyga, does it work with other shells or only with bash?
[08:34] <zyga> I don't know
[08:34] <zyga> bash has command_not_found_handle
[08:34] <zyga> if other shells have similar hooks this can work anywhere
[08:34] <zyga> the program is written in python
[08:36] <carlos> zyga, dude, that's so cool :-D
[08:36] <zyga> carlos: sivang is working on windows suggestions
[08:37] <zyga> maybe it's silly but for photoshop you will be advised to install gimp
[08:37] <zyga> it's good for other unices though
[08:37] <zyga> like for solaris
[08:37] <carlos> zyga, the problem is that people does not execute windows applications from the console at least is not something usual
[08:37] <zyga> aix or others
[08:37] <zyga> carlos: well that's not the idea anyway
[08:37] <zyga> (the windows part was only a tech test drive)
[08:38] <zyga> we can put all solaris specific commands and give explanations about linux counterparts
[08:38] <kiko> zyga, that is so cool dude
[08:38] <zyga> same stuff for redhat stuff
[08:38] <zyga> :>
[08:38] <zyga> so fresh converts will pick up new tools quicky and start working instead of googling
[08:38] <zyga> and think, darn this ubuntu thing is nice :)
[08:51] <bradb> zyga: dude, you rock
[09:17] <niemeyer> When I introduce something new in config/default/launchpad.conf, should I include it in every other config as well (production, staging, etc)?
[09:17] <niemeyer> Or is it done on demand?
[09:18] <niemeyer> (IOW, when the option is truly needed)
[09:19] <salgado> niemeyer, AIUI, yes, you should do it. otherwise stub will have to add them when he run that in production/staging
[09:19] <niemeyer> salgado: Ok, thanks
[09:21] <salgado> niemeyer, you're welcome
[10:57] <bradb> my cool command line hack of the day:
[10:57] <bradb> find . -name "*" | xargs file | perl -pe 's/^.+:\s+(.*)$/$1/' | sort | uniq -u
[10:58] <bradb> debugging a problem with a search feature of a new editor I'm trying out, i wanted to get a list of all file types under the current dir. that seems to have worked, roughly.
[10:58] <\sh> bradb: hey :)
[10:59] <\sh> 'alps-light1' couldn't be found in command 'affects /distros/ubuntu/alps-light1'
[10:59] <kiko> what does the perl do?
[10:59] <\sh> that's what I got as reply trying to send this by mail to malone :) 
[10:59] <bradb> kiko: my intent was for it to extract only the type info out of the "file" input. seems to have worked.
[10:59] <kiko> is that how you file bugs on source packages using the email interface?
[11:00] <bradb> \sh: looking, one sec
[11:00] <\sh> kiko: no...that was the answer to a correct new bugreport 
[11:00] <\sh> kiko: seeing that everything else worked :)
[11:01] <kiko> \sh, I'm confused.
[11:01] <kiko> what bug did you file?
[11:02] <\sh> kiko: we are filing merging bugs in malone...via email interface...from 170 bugs filed with a small util we wrote, only this one was failing :)
[11:02] <\sh> https://launchpad.net/people/shermann/+reportedbugs check it :)
[11:03] <BjornT> \sh: i'm working on improving the error messages over the next week ;) the error you got should mean that the package doesn't exist in malone
[11:03] <\sh> BjornT: ah...this is something else :) who is responsible to add packages to a distro? 
[11:04] <bradb> \sh: apt doesn't know about that package, it appears
[11:04] <ajmitch> BjornT: how long does it generally take for launchpad to see that I filed a bug via email?
[11:04] <\sh> bradb: sure...it's in breezy
[11:04] <\sh> aeh dapper
[11:05] <bradb> ah, dapper
[11:05] <\sh> apt-get source alps-light1 
[11:05] <bradb> we don't have dapper data in launchpad, AFAIK
[11:05] <ajmitch> bradb: yeah, we only care about dapper now :)
[11:05] <bradb> a useful error message could have helped made this clear
[11:05] <ajmitch> it's fairly important that we get the package data in, I think
[11:05] <\sh> bradb: ok...so there is a diff between the breezy source packages and dapper sources
[11:06] <\sh> -ENOTMYFAULT :)
[11:06] <bradb> kiko: presumably this is blocked on a gina run, right?
[11:06] <BjornT> ajmitch: it shouldn't take more than a couple of minutes. i'll check if your message caused an error
[11:06] <ajmitch> BjornT: or it could be some slow mailservers somewhere - I sent from ajmitch@ubuntu.com if it helps you look it up
[11:06] <\sh> BjornT: to report the times...this error message took 3 mins longer then a positive answer of malone
[11:07] <kiko> bradb, yes, it is.
[11:07] <kiko> ajmitch! did you note my email?
[11:07] <kiko> ajmitch, your email is getting dropped
[11:07] <kiko> because IIRC your key is not registered
[11:07] <ajmitch> great
[11:07] <kiko> I wrote to you about it
[11:07] <ajmitch> I registered my key back at UBZ
[11:07] <ajmitch> I didn't see your email
[11:08] <kiko> Unknown user: Andrew Mitchell <ajmitch@ajmitch.dhis.org>
[11:08] <ajmitch> hm
[11:08] <bradb> ajmitch, \sh: so, getting the package information in is blocked on a successful gina run. i don't know when this will happen, but kiko probably does. sorry for the confusion/misery that this will cause in the meantime.
[11:08] <kiko> I think this email isn't registered in launchpad, actually.
[11:08] <ajmitch> it's not
[11:08] <kiko> wtf
[11:08] <ajmitch> and it shouldn't be sending from that address
[11:08] <\sh> bradb: no prob at all...I just wondered what happend :) 
[11:08] <kiko> it will happen soon
[11:08] <kiko> ajmitch, "it"? :)
[11:08] <ajmitch> so I can blame \sh's script ;)
[11:08] <kiko>  bradb@canonical.com
[11:08] <kiko>     SMTP error from remote mail server after RCPT TO:<bradb@canonical.com>:
[11:08] <kiko>     host fiordland.warthogs.hbd.com [82.211.81.145] :
[11:08] <kiko>     550 <bradb@canonical.com>: Recipient address rejected:
[11:08] <kiko>     User unknown in virtual alias table
[11:08] <kiko> bradb, wtf?
[11:08] <ajmitch> kiko: the dhis.org address isn't in launchpad, and shouldn't be used
[11:09] <bradb> kiko: !?
[11:09] <bradb> i didn't send that
[11:09] <kiko> that's what /I/ got
[11:09] <kiko> ajmitch, ah, okay.
[11:09] <kiko> well
[11:09] <kiko> that's why it's bouncing
[11:09] <kiko> ajmitch, you don't read my emails? :-(
[11:10] <ajmitch> kiko: I didn't get your mails
[11:10] <ajmitch> sorry
[11:10] <bradb> kiko: that email never worked, AFAIK. it's brad.bollenbach
[11:10] <bradb> i'm not good enough for $nick@canonical.com
[11:11] <ajmitch> kiko: were they important emails?
[11:13] <kiko> bradb, you are definitely good enough, you might as well request it.
[11:13] <kiko> ajmitch, well, emails saying that the bugs you filed were dropped!
[11:13] <bradb> kiko: do i have to open an RT ticket for these types of things now, and if so, where's the RT instance at?
[11:14] <kiko> bradb, I think you can find this information on the wiki, but yes
[11:14] <ajmitch> \sh: changing the send method to smtp fixes the from address in the envelope
[11:14] <kiko> alias rt-canonical Canonical Admins\' RT <rt@admin.canonical.com>
[11:14] <\sh> ajmitch: aehm
[11:14] <kiko> bradb, that's the one
[11:14] <\sh> ajmitch: use smtp auth
[11:15] <\sh> ajmitch: or fix your mta
[11:15] <ajmitch> :P
[11:15] <\sh> ajmitch: for postfix this is easy
[11:15] <bradb> kiko: thanks
[11:15] <ajmitch> we'll see if the ones I'm filinf again get through
[11:15] <kiko> \sh, wow, amazingly cool work
[11:15] <\sh> ajmitch: do you need somehow a working SMTP server with SMTP AUTH 
[11:15] <\sh> kiko: what? the bugs...or the script?
[11:15] <ajmitch> ah that was a lot quicker
[11:16] <ajmitch> bugs filing alright now, sorry about the hassle :)
[11:16] <\sh> kiko: bzr branch http://tiber.tauware.de/~shermann/motu-tools -> take a look on lpbugs.py
[11:17] <\sh> kiko: 1h hack for a handy motu LP tool in python 
[11:19] <\sh> and a "so to be replacement" for reportbugs but LP based is in production..with a nice GUI (gtk and hopefully qt) for latest dapper+1
[11:19] <ajmitch> much better than the hackjob I was writing during breezy ;)
[11:20] <ajmitch> \sh: can you resend sistpoty's mail to the ihug.co.nz address, btw? something is going slow with the ubuntu.com address
[11:20] <ajmitch> I should talk to someone about it - mails to mdz got lost at some point
[11:20] <\sh> ajmitch: i did
[11:20] <ajmitch> hm
[11:21] <kiko> \sh, are you serious about reportbug?
[11:21] <\sh> kiko: yes...I had a look on reportbug and too many switches too many options for the normal user...
[11:22] <\sh> kiko: so I'm writing a tool where u search the package...(just a few characters..and u get a list of all packages sorted by source package names and versions)
[11:22] <\sh> u choose...write the bug report...and send it straight away to malone
[11:23] <kiko> wow
[11:23] <kiko> that is so cool
[11:23] <kiko> we were discussing this at UBZ!
[11:24] <\sh> if u want to have a status update, it searches for the productname == packagename in the subject of your reported bugs, or searches through LPs advanced bug query page..(but I want to have actually something xml-ish or xmlrpc interface) 
[11:24] <\sh> and should fetch the bugs for this package...
[11:25] <\sh> kiko: what I need is something where I can query easily the bug database...best would be a xmlrpc interface..with some lightweight functions
[11:25] <kiko> yes, we need to work on that, but it's not for this next 3 months.
[11:25] <kiko> \sh, does your tool do the same data collection that reportbug does?
[11:25] <\sh> kiko: we have time...we're just busy with the merges and transitions...and after UVF I can work fulltime on it
[11:26] <bradb> \sh: maybe i missed this, but how do you plan to handle authentication?
[11:26] <\sh> kiko: I want to implement this
[11:26] <bradb> \sh: I think auth can be reasonably pulled off if we turn off password auth for the email and XML-RPC interfaces (i.e. rely on identification instead)
[11:26] <\sh> kiko: completly automagically and hiding from the user...less user interaction, more data, but easy to handle..only the bugreport and LP data has to be set (and the email conf(
[11:28] <kiko> I wonder if we need a special structure to store the data we collect. we've mused about this in the past.
[11:28] <kiko> this could tie in to ogra's hwdb stuff
[11:29] <\sh> for the time, when there is no xmlrpc interface or no easy way to fetch a full list of bugreports for e.g. "query assignee" I will setup a public imap folder on tiber ( canonical sponsored motu server for revu and stuff like this) to fetch the bug reports from there
[11:29] <\sh> in a similar way as we do now on http://revu.tauware.de/~sistpoty/MoM/index.py
[11:30] <kiko> hmmm
[11:30] <\sh> bradb: well...the interface is completly indipendent from the gui :) 
[11:31] <\sh> bradb: so we can write as well a cli only client
[11:31] <kiko> \sh, you know that reportbug has pluggable backends, right?
[11:31] <\sh> bradb: thats why I can write the gui for two desktops
[11:31] <bradb> cool
[11:31] <\sh> kiko: yes..read the manpage..when I imagine I'm a normal user, it would scare the hell out of my brain
[11:32] <\sh> even bugzilla is easier then reportbug (IMHO)
[11:32] <thierry> when a bug is set as a duplicate, he stays has "New"... couldn't we change that? because sometime when we look at a list of bug it just shows "New" and you don't know it's a duplicate
[11:33] <kiko> thierry, dupes are filtered from buglists unless someone has undone my patch.
[11:33] <thierry> kiko : well not from bug list that open when you're watching a bug and you look at the right bottom list of the bugs that are from the same package...
[11:34] <kiko> thierry, ah. that's a good point. should dupes be filtered from that, thierry?
[11:34] <thierry> kiko : look there : https://launchpad.net/distros/ubuntu/+source/vim/+bug/3222 
[11:34] <Ubugtu`> Malone bug #3222: gvim does not have a menu entry Fix req. for: vim (Ubuntu), Severity: Minor, Assigned to: MOTU, Status: Accepted http://launchpad.net/malone/bugs/3222
[11:35] <thierry> kiko : well yes! other ways we are wasting time watching bugs that are dups of bugs that are already fixed!
[11:35] <thierry> if you look at the link, right bottom list, bug 3743 is new but duplicated of a fixed bug
[11:35] <Ubugtu`> Malone bug #3743: gvim.desktop should not be packaged with vim Fix req. for: vim (Ubuntu), Severity: Minor, Assigned to: Nobody, Status: New http://launchpad.net/malone/bugs/3743
[11:35] <kiko> okay.
[11:35] <kiko> good point.
[11:35] <kiko> can you file the bug?
[11:35] <kiko> I have just the person to fix it
[11:36] <bradb> thierry: good catch.
[11:36] <thierry> kiko : where do I fill it?
[11:36] <thierry> bradb : thanks :)
[11:36] <kiko> thierry, on malone.
[11:36] <bradb> thierry: launchpad.net/products/malone/+bugs
[11:36] <thierry> thanks going to do that
[11:36] <bradb> the "Report a Bug" link
[11:39] <thierry> kiko , bradb : bug 4837
[11:39] <Ubugtu`> Malone bug #4837: right bottom bug list duplicate problem Fix req. for: malone (upstream), Severity: Normal, Assigned to: Nobody, Status: New http://launchpad.net/malone/bugs/4837
[11:39] <bradb> thierry: you rock, thanks for taking the time to help out
[11:39] <kiko> bradb, sounds like matsubara-task?
[11:39] <bradb> kiko: sure
[11:40] <kiko> cool
[11:40] <\sh> we need an adultcheck for LP pr0n content...depending on geo-ip based location services and sex detection for MoF
[11:44] <jordi> \sh: does this have anything to do with the Pornlets?
[11:45] <kiko> it must
[11:45] <\sh> yes...
[11:51] <jordi> kiko: It is time to unveil the MOCKUP
[11:52] <kiko> omg
[11:56] <jordi> DONE
[11:57] <bradb> that is HOT!!@J!
[11:57] <jordi> haha
[11:58] <bradb> it's about time there were some smooth curves in portlets
[12:01] <jordi> nite brad