[01:12] <mpool> hello
[01:16] <kiko> hi there mpool 
[02:00] <mpt_> lifeless, it's not by design, it's by crapitude, and it's overdue to be replaced
[02:01] <mpt_> oh
[02:01] <kiko-zzz> ZZZZ
[03:13] <jamesh> mpt_: what do you think of kiko's alternative phrases for the person details portlet? (assuming they get switched to all first person or all second person)
[03:30] <mpt_> Goooooooooooooooood afternoon Launchpadders!
[03:31] <Burgundavia> hey mpt_
[03:55] <jamesh> brilliant: https://launchpad.net/products/costato (check what project it is registered with)
[03:58] <mpt_> yay
[04:02] <mpt_> see also bug 45419
[04:02] <mpt_> Can someone please kick staging?
[04:03] <mpt_> (and kick Ubugtu, too)
[04:08] <mpt_> bug 45419
[04:08] <Ubug2> Malone bug 45419 in launchpad "Launchpad needs a way of easily flagging spam" [Medium,Confirmed]  http://launchpad.net/bugs/45419
[04:20] <jamesh> mpt_: did you see my message earlier (about an hour ago?)
[04:22] <mpt_> jamesh, yes, but I hadn't found kiko's suggestions yet
[04:23] <mpt_> ah
[04:23] <mpt_> jamesh, I don't like any of them particularly :-)
[04:25] <jamesh> okay.  I told kiko I'd bring it up with you today :)
[04:30] <mpt_> jamesh, what is necessary to use pqm-submit from devpad? Can I follow the same instructions as for installing it locally?
[04:31] <jamesh> mpt_: how do you send email normally?
[04:31] <jamesh> mpt_: you can configure pqm-submit to use a remote SMTP server rather than local
[04:33] <mpt_> really?
[04:33] <jamesh> yeah
[04:33] <mpt_> bzr pqm-submit --help doesn't mention anything about that
[04:33] <jamesh> edit ~/.bazaar/bazaar.conf and add a line like "smtp_server = mail.example.com"
[04:34] <jamesh> and it will send it to that machine for delivery rather than the local MTA
[04:34] <mpt_> great, thanks
[04:35] <jamesh> mpt_: it is possible to configure postfix to forward all mail to another MTA too, which might fix your problem
[04:35] <mpt_> I think this is a DNS problem rather than an MTA problem
[04:35] <jamesh> but the ~/.bazaar/bazaar.conf option is probably simpler in the short run
[04:36] <mpt_> host anything.tld produces a warning message about malformed packets
[04:36] <jamesh> well, it'll be your ISP's problem to resolve the destination address if you send it there ...
[04:36] <mpt_> yeah
[04:38] <mpt_> hi Burgundavia 
[04:38] <mpt_> ok, let's see if this works
[04:39] <mpt_> bah
[04:39] <mpt_> bzr: ERROR: socket.error: nonnumeric port at /usr/lib/python2.4/smtplib.py line 291
[04:40] <mpt_> oh, that'll be because my smtp server is of the form mail.foo.bar:mpt@foo.bar
[04:40] <mpt_> and bzr thinks mpt@foo.bar is a port number
[04:54] <jamesh> I don't think the pqm-submit plugin has support for SMTP auth
[04:54] <mpt_> yeah, I was just coming to that conclusion
[04:54] <mpt_> It's not mentioned anywhere in http://bzr.arbash-meinel.com/plugins/pqm-submit/pqm_submit.py
[04:54] <mpt_> I'll report a bug
[04:54] <jamesh> your ISP requires it?
[04:54] <mpt_> yes, I got an error without it
[04:55] <jamesh> good ISP, bad pqm-submit plugin then :)
[04:55] <mpt_> Meanwhile, is running pqm-submit from devpad the next best option?
[04:57] <jamesh> mpt_: as a temporary solution, you could try hacking auth into the plugin
[04:57] <jamesh> mpt_: edit pqm_submit.py and add a line like this before the smtp.sendmail() command: smtp.login('username', 'password')
[04:59] <jamesh> mpt_: the other option is to do "bzr pqm-submit --dry-run" and paste message body into your normal mailer.  This requires that the mailer not rewrap the message though
[05:02] <mpt_> reported bug 58284
[05:02] <Ubug2> Malone bug 58284 in Ubuntu "Buffer I/O Error on device hdc, logical block 25678" [Medium,Needs info]  http://launchpad.net/bugs/58284
[05:03] <mpt_> make that bug 58294
[05:03] <Ubug2> Malone bug 58294 in bzr-pqm "smtp_server option doesn't allow authentication" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58294
[05:04] <mpt_> WOOHOO
[05:04] <mpt_> Thank you jamesh
[05:21] <jamesh> mpt_: out of interest, why did you think that "host:user@password" would be accepted for the smtp_server value?  Do other pieces of software accept that form?
[05:25] <somerville32> Ewww...
[05:26] <mpt_> jamesh, that's how it's represented in URLs, and also in Apple Mail's server menu
[05:27] <jamesh> actually, it is usually "user:password@host" in URLs
[05:29] <mpt_> ah
[05:29] <mpt_> I guess that would have failed the same way, though
[05:29] <mpt_> complaining that password@host wasn't a valid port number
[05:54] <mpt_> jamesh, why is tickcount part of launchpad-project?
[05:55] <jamesh> mpt_: it is code produced by the Launchpad project?
[05:55] <jamesh> and will be used in launchpad for the error reporting in the future
[05:56] <jamesh> (so that we can get some idea of how much work is done in Python for various phases of processing a request)
[06:00] <mpt_> ok, just checking :-)
[06:01] <mpt_> I didn't see anything about Launchpad in the product description
[06:10] <Ubug2> New bug: #58297 in launchpad "Costato product should not have been able to join the Launchpad project" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58297
[06:19] <jamesh> mpt_: well, this is what the non-active person page now looks like: https://staging.launchpad.net/people/mzqrovna
[06:41] <mpt_> jamesh, neat
[06:42] <jamesh> It'd be good to get rid of the automatic wikiname creation at some point
[06:43] <jamesh> and get our hacked moin to treat the LP page as the user page
[06:43] <jamesh> and just display LP usernames as the short names
[06:45] <Burgundavia> jamesh: I would love you for that, except the LP pages need to allow more than a few lines they currently do
[06:45] <jamesh> Burgundavia: can't you put as much text as you want on the LP person page?
[06:46] <Burgundavia> what about images, links to other wiki pages, etc.
[06:47] <jamesh> arr.  mpt has a spec he wants me to look at implementing for that.
[06:47] <mpt_> Burgundavia, We Have Plans(TM) for person(/product/project/etc) descriptions that can contain fancy stuff like links
[06:47] <jamesh> allowing wiki syntax for some of this
[06:47] <Burgundavia> ok, that is good
[06:47] <mpt_> but it wouldn't include WikiLinks automatically
[06:48] <Burgundavia> and before you turn such a feature on, you had better tell everybody
[06:48] <Burgundavia> and provide wiki style rollback, etc.
[06:48] <mpt_> you'd have to do those [https://wiki.ubuntu.com/HelpOnLinking manually] 
[06:48] <jamesh> unless we did interwiki shit
[06:49] <Burgundavia> if you bring moin within LP, you could kill the bloody moronic split spec stuff
[06:49] <jamesh> I'd like to see special syntax for linking to projects, bugs, etc
[06:49] <jamesh> e.g. [bug:5000]  or similar
[06:50] <Burgundavia> that would be brilliant
[06:50] <Burgundavia> you need more robust changes tracking
[06:50] <Burgundavia> trac style timelines would rock
[06:56] <jamesh> Burgundavia: do you know if edgy will have Python 2.5 in, by any chance? :)
[06:56] <Burgundavia> already uploaded, but no idea if by default
[06:57] <jamesh> some of the new features look very nice
[06:58] <Burgundavia> I will take your word for it. I let smarter people do crazy things like actually produce code ;)
[07:00] <crimsun> /usr/share/python/debian_defaults still lists python2.4 as default
[07:00] <Burgundavia> crimsun: yep, but 2.5 is in the repos
[07:00] <crimsun> right.
[07:02] <Burgundavia> anybody got compiz running?
[07:06] <mpt_> Burgundavia, yes, the main rationale is to end the silly spec split :-)
[07:07] <Burgundavia> oh praise the lord. God kills a baby jesus everytime I have to deal with that
[07:08] <jamesh> crimsun: not too surprising given 2.5 hasn't been released.  Having it available is nice though.
[07:08] <Burgundavia> rc 1, currently
[07:12] <jamesh> it means we may be able to start using it six months earlier in launchpad
[07:14] <jamesh> only need to wait til edgy is on the servers rather than edgy+1
[07:14] <Burgundavia> yep
[07:20] <Burgundavia> further question: has there been much movement on the open sourcing of rosetta and malone?
[07:22] <jamesh> not since you brought it up earlier this week.
[07:22] <mpt_> heh
[07:23] <Burgundavia> if I hammer away long enough, the wall will come down
[08:10] <mpt_> Burgundavia, Launchpad is not the Shawshank Redemption
[08:11] <Burgundavia> mpt_: "Mr Shuttleworth, tear down this wall!" ;)
[08:20] <jamesh> two more merges and we hit revision 4000
[08:34] <mpt_> I knew Ronald Reagan. Ronald Reagan was a friend of mine. And you, Burgundavia, are no Ronald Reagan.
[08:34] <Burgundavia> Eich ein Launchpadder!
[08:35] <mpt_> mmmmmm, donuts
[08:35] <SteveA> morning
[08:38] <Burgundavia> morning SteveA
[08:41] <SteveA> hey corey
[08:41] <sivang> Morning
[08:46] <SteveA> morning sivan
[08:46] <SteveA> mpt_: morning.  i have ssh access to a server I'll call "brilliant" now.
[08:47] <sivang> morning SteveA 
[09:03] <carlos> morning
[09:06] <SteveA> hi carlos
[09:06] <carlos> hi
[09:09] <SteveA> mpt_: have you seen http://developer.spikesource.com/wiki/index.php/Projects:TestGen4Web ?
[09:09] <xerxas> Hi everyone
[09:09] <xerxas> is it possible to merge 2 accounts ? 
[09:09] <xerxas> I have one for my irc nick, one for my real name 
[09:10] <xerxas> I want to keep my karma ;) (even thought it's pretty low ) 
[09:10] <mdke> xerxas: on the page https://launchpad.net/people there is a link to merge accounts
[09:10] <spiv> xerxas: https://launchpad.net/people/+requestmerge
[09:10] <xerxas> ok
[09:10] <xerxas> thanks 
[09:10] <spiv> (which is the link mdke is referring to)
[09:10] <mdke> :)
[09:23] <xerxas> this have resetted my karma to 0 ;( 
[09:23] <xerxas> not really important when you have a karma of arrount 600 
[09:23] <xerxas> ;)
[09:23] <mdke> that certainly shouldn't happen. Maybe you have to wait for a while
[09:23] <lifeless> the cache will regen in < 24 hours
[09:24] <lifeless> it will then come back
[09:24] <jamesh> lifeless: feeling better?
[09:25] <lifeless> I've stopped sneezing, still have puffy eyes, sinus and headache
[09:25] <spiv> xerxas: If you look at your https://launchpad.net/people/<name>/+karma page, you'll see the karma actions are still in there, so it's just a matter of waiting for the number to be regenerated
[09:25] <lifeless> just passing through to get orange juice
[09:25] <lifeless> perhaps we should show 'an unknown' amount for the karma of merged accounts ?
[09:25] <spiv> They've finally invented OJ-over-IRC?
[09:26] <lifeless> or perhaps we should just sum the records in the cache, as an approximation
[09:26] <spiv> lifeless: we could simply add the karma of the merged user into the existing one I'd think.
[09:30] <jamesh> SteveA: so, someone registered a product under the Launchpad project today
[09:31] <jamesh> who has nothing to do with LP.
[09:37] <SteveA> jamesh: interesting.  maybe they thought they had to register their product with launchpad.
[09:38] <jamesh> given that it got a productseries, they must have registered it with /products/+new
[09:38] <jamesh> rather than /projects/launchpad-project/+newproduct
[09:41] <jamesh> (I did a fix today to make sure you get a default trunk series when creating products through the $PROJECT/+newproduct page today)
[09:44] <xerxas> spiv, ok, thanks 
[10:16] <mpt_> hi SteveA 
[10:17] <mpt_> SteveA, no, I hadn't seen it
[10:19] <SteveA> mpt_: would you be interested in spending an hour or so looking at it, see if it can be useful for us?
[10:20] <mpt_> SteveA, ok, though my to-do list is botheringly long
[10:31] <SteveA> mpt_: that's fine.  I don't want to over-extend your todo list
[11:04] <mpool> SteveA: hi, want to come to the merlinux meeting?
[11:52] <danilos> carlos: ping
[11:52] <carlos> danilos: pong
[12:11] <jamesh> mpt_: ping?
[12:11] <mpt_> jamesh, pong
[12:12] <jamesh> mpt_: I did up a quick script to address bug 42884
[12:12] <Ubugtu> Malone bug 42884 in malone "Duplicate markings from bugzilla.ubuntu.com shouldn't link to irrelevant bugs" [Medium,Confirmed]  http://launchpad.net/bugs/42884
[12:12] <jamesh> mpt_: I ran it on https://demo.launchpad.net/ if you want to see what the results look like
[12:13] <jamesh> note the lack of [https://launchpad.net/malone/bugtrackers/ubuntu-bugzilla/NNNN]  bits in comments, and the way the bugs actually link to the right places ...
[12:15] <ddaa> good morning
[12:26] <sivang> morning ddaa 
[12:28] <jordi>     - discussion on rosetta/ubuntu upstream adoption with kiko
[12:28] <jordi> danilos: is there a log of this?
[12:28] <jordi> do you think it's interesting for me to read/know more?
[12:29] <danilos> jordi: nope, well, it was a discussion on what privilege levels we want to have
[12:29] <jordi> oh ok
[12:29] <danilos> jordi: you'll definitely get informed about it once we start a spec on it (and I really should do that)
[12:29] <danilos> if there isn't one already
[12:29] <jordi> k
[12:30] <jordi> today's goal, finish KDE mail
[12:30] <jordi> it's taking me time because I have to analyse both their questions and their answers
[12:30] <jordi> (besides there's been a lot more going on)
[12:30] <mpt_> jamesh, do you have a handy example of an imported b.u.c bug?
[12:31] <jordi> danilos: heh, I see you've been catching up too on reports
[12:31] <jamesh> mpt_: https://launchpad.net/distros/ubuntu/+source/xorg/+bug/14899 <- this one seems to be the one you complained about in the initial message
[12:31] <Ubugtu> Malone bug 14899 in xorg "setup sets PC keyboard layout on macs" [Low,Confirmed]  
[12:32] <jamesh> mpt_: compare it with the demo.launchpad.net version
[12:33] <jamesh> https://launchpad.net/distros/ubuntu/+source/xorg/+bug/14899/comments/7 vs https://demo.launchpad.net/distros/ubuntu/+source/xorg/+bug/14899/comments/7
[12:33] <Ubugtu> Malone bug 14899 in xorg "setup sets PC keyboard layout on macs" [Low,Confirmed]  
[12:33] <mpt_> duh, I should read my own bug reports
[12:35] <mpt_> jamesh, nice work!
[12:36] <jamesh> the script is not particularly pretty, but it should only need to be run once in production
[12:36] <jamesh> I'll clean it up when I adapt it to the SF import
[12:37] <jamesh> after that's done, I wonder if it is worth keeping the bug watches around ...
[12:48] <mpt_> jamesh, I've been meaning to file an RT ticket to redirect from bugzilla.ubuntu.com/show_bug.cgi to the equivalent Launchpad report, and to require auth only for non-showbug URLs
[12:48] <mpt_> Does that seem sane?
[12:49] <mpt_> That way you will wouldn't be able to land on b.u.c, but old Bugzilla bug URLs wouldn't be broken
[12:49] <mpt_> will -> still
[01:06] <jamesh> mpt_: maybe.  How many old bugzilla links do we still run into?
[01:12] <mpt_> jamesh, I have no idea
[01:12] <mpt_> I don't have access to the relevant stats :-)
[01:15] <lifeless> gnight
[01:16] <teolemon> good night
[01:55] <malcc> Meeting in 5
[01:57] <SteveA> today, malcolm has agreed to chair the launchpad developers' meeting
[02:00] <malcc> Ok, it's time for...
[02:00] <danilos> me?
[02:00] <malcc> The Launchpad Developers Meeting!
[02:00] <danilos> ;)
[02:00] <malcc> Who's here?
[02:00] <bradb> me
[02:00] <mpt_> me
[02:00] <jamesh> me
[02:00] <spiv> me
[02:00] <ddaa> His shoe!
[02:00] <SteveA> me
[02:00] <cprov> me
[02:00] <danilos> me again (count me twice!)
[02:00] <flacoste> me
[02:00] <ddaa> me
[02:00] <kiko-zzz> me
[02:00] <BjornT> me
[02:01] <salgado> me
[02:01] <ddaa> me (I'm the launchpad-bazaar team pair, all by myself, ya know)
[02:01] <malcc> Apologies from stub (hols) and lifeless (poorly)
[02:01] <danilos> carlos: ping
[02:01] <carlos> me
[02:01] <matsubara> me
[02:01] <malcc> Anyone else missing?
[02:01] <SteveA> jordi: (if available)
[02:01] <kiko> not me
[02:01] <SteveA> mpool: if available
[02:02] <malcc> == Agenda ==
[02:02] <malcc>  * Roll call
[02:02] <malcc>  * Agenda
[02:02] <malcc>  * Next meeting
[02:02] <malcc>  * Activity reports
[02:02] <malcc>  * Actions from last meeting
[02:02] <malcc>  * Oops report (Matsubara)
[02:02] <malcc>  * Bug report report (mpt)
[02:02] <malcc>  * Production and staging (Stuart)
[02:02] <malcc>  * Launchpad 1.0 status reports
[02:02] <malcc>  * Sysadmin requests
[02:02] <malcc> ----
[02:02] <malcc>  * Timely bug triage (bradb)
[02:02] <malcc>  * Testing bzr release candidate (Steve)
[02:02] <malcc>  * (other items)
[02:02] <malcc> ----
[02:02] <malcc>  * Keep, Bag, Change
[02:02] <malcc>  * Three sentences
[02:02] <malcc> Next meeting
[02:02] <malcc> Next week
[02:02] <malcc> Any objections?
[02:02] <malcc> 5
[02:02] <malcc> 4
[02:02] <malcc> 3
[02:03] <malcc> 2
[02:03] <malcc> 1
[02:03] <malcc> Done
[02:03] <malcc> Activity reports
[02:03] <malcc> Who's up to date?
[02:03] <SteveA> i'm not
[02:03] <malcc> I am
[02:03] <matsubara> up to date
[02:03] <kiko> I'm not this week either
[02:03] <mpt_> not up to date
[02:03] <bradb> up to date
[02:03] <flacoste> up to date
[02:03] <danilos> up to date (some summarizing, some batching)
[02:03] <BjornT> i'm up to date
[02:03] <jamesh> I sent a batched summary
[02:03] <jordi> hello!
[02:03] <jordi> sorry
[02:03] <carlos> I'm one day behind (will send it today)
[02:03] <salgado> up to date
[02:03] <jordi> big news -- I'm up to date
[02:03] <spiv> up to date
[02:04] <ddaa> up to date
[02:04] <mpt_> yay for jordi
[02:04] <malcc> cprov?
[02:04] <cprov>  up to date, sorry
[02:05] <malcc> Ok, actions from last meeting
[02:05] <malcc>  * SteveA to update infrastructure specs if /$name is needed for 1.0
[02:05] <mpool> (me is here)
[02:05] <malcc>  * SteveA to put up a wiki page for the launchpad project to note disaster scenarios on, and mail the list about it
[02:05] <SteveA> not yet
[02:05] <SteveA> and not yet also
[02:05] <malcc>  * stub to check that bug 57474 isn't an SQL injection attack vector
[02:05] <Ubugtu> Malone bug 57474 in launchpad "Passing a list as the query string in the product search field crashes ftq" [High,Confirmed]  http://launchpad.net/bugs/57474
[02:05] <SteveA> not yet
[02:06] <malcc> Cool, 0 out of 3, go us :)
[02:06] <malcc> Ok: Oops report (Matsubara)
[02:06] <malcc> matsubara: All yours
[02:06] <matsubara> Today's oops report is about bugs 37865, 54303
[02:06] <Ubugtu> Malone bug 37865 in launchpad-support-tracker "Support listing could use a list similar to the bug listing" [Medium,In progress]  http://launchpad.net/bugs/37865
[02:06] <Ubugtu> Malone bug 54303 in malone "Rendering a bug with many comments causes timeouts in TAL." [Medium,Confirmed]  http://launchpad.net/bugs/54303
[02:06] <matsubara> flacoste bug 37865 is in progress for quite some time. How's it going?
[02:06] <flacoste> it's in review
[02:07] <flacoste> actually, it's now up for a second review
[02:07] <flacoste> and should land soon
[02:07] <matsubara> flacoste: ok, thanks. I forgot to check the PR page...
[02:07] <matsubara> bug 54303 is not assigned. Who could take that one? Some discussion started yesterday about it in launchpad@ and kiko and BjornT suggested a ways to fix it. Any other suggestions how to improve TAL rendering?
[02:07] <Ubugtu> Malone bug 54303 in malone "Rendering a bug with many comments causes timeouts in TAL." [Medium,Confirmed]  http://launchpad.net/bugs/54303
[02:07] <kiko> matsubara, I think we're not considering fixing TAL to be faster, but just to generate the comments using pure python.
[02:08] <kiko> and then do a simple tal:replace="structure view/getCommentHTML"
[02:08] <kiko> I'm not volunteering this week, but perhaps next week or the other.
[02:08] <kiko> if you can convince BjornT to do it I'm happy
[02:08] <matsubara> kiko: ok, that's not a very common issue, so no need to hurry
[02:09] <matsubara> but it would be nice to have a solution that could be used in other places.
[02:09] <matsubara> like the tickets page for instance
[02:09] <kiko> matsubara, the only solution would be to fix TAL rendering.
[02:09] <kiko> [to be faster] 
[02:09] <kiko> any other solution will be pretty specific to the view in question
[02:09] <flacoste> i thinkg that BjornT comment about batching was pertinent
[02:10] <flacoste> i.e. any pages that could grow very big should be batched
[02:10] <kiko> so I'm not in favor of batching because of the UI. Bugzilla /never/ had to do batching to get a bug page to render in 0.001ms, so we should not have to do it for performance reasons.
[02:10] <kiko> if we want to do batching because it makes for better UI, I'm all for it
[02:10] <kiko> but I didn't see a proposal in that direction
[02:10] <jamesh> bugzilla seems to take a long time for huge bug conversations
[02:10] <kiko> the proposal I saw was "TAL rendering is slow, so let's batch"
[02:10] <jamesh> not 0.001ms
[02:11] <jamesh> (not to say we don't have room for improvement)
[02:11] <ddaa> incremental page download will help too
[02:11] <kiko> jamesh, I was exaggerating.
[02:11] <matsubara> other thing that BjornT pointed is the size of the page
[02:11] <mpt_> I think batching would be silly
[02:11] <bradb> me too
[02:11] <mpt_> UI-wise, anyway
[02:11] <kiko> UI-wise I agree
[02:12] <SteveA> tal:repeat is slow
[02:12] <ddaa> it's fine for long page to be long to download, as long as some stuff happens quickly
[02:12] <bradb> if anything, that seems to be pushing more towards collapsing comments
[02:12] <mpt_> so, maybe KeepingBugsConcise is important after all ;-)
[02:12] <kiko> okay, okay, okay
[02:12] <spiv> ddaa: well, it's fine for the user perhaps, but still not so good for our busy servers :)
[02:12] <kiko> so IF I find time today I'll try moving the HTML rendering to python
[02:12] <kiko> no promises
[02:12] <malcc> Ok cool.
[02:13] <malcc> matsubara: Anything else?
[02:13] <ddaa> incremental download also reduces the total user-visible time, since client rendering is parallelised with server rendering.
[02:13] <matsubara> malcc: I'm done, thanks.
[02:13] <malcc> matsubara: Thanks
[02:13] <malcc> Next up: Bug report (mpt)
[02:13] <malcc> mpt_: Your move
[02:13] <mpt_> There are 14 Critical open bugs in Launchpad. These are the oldest six:
[02:13] <mpt_>  * Bug 2497 (/people/*/+translations times out for prolific translators), Critical, Confirmed, stub
[02:13] <mpt_> stub, how's it going?
[02:13] <Ubugtu> Malone bug 2497 in rosetta "/people/*/+translations times out for prolific translators" [Critical,Confirmed]  http://launchpad.net/bugs/2497
[02:13] <mpt_>  * Bug 30264 (P-A-S support needs proper binary-only excludes), Critical, Confirmed, unassigned
[02:13] <Ubugtu> Malone bug 30264 in soyuz "P-A-S support needs proper binary-only excludes" [Critical,Confirmed]  http://launchpad.net/bugs/30264
[02:13] <mpt_> cprov, malcc, who should get that?
[02:13] <mpt_>  * Bug 30602 (Timeout errors in +translate), Critical, Confirmed, danilos
[02:13] <Ubugtu> Malone bug 30602 in rosetta "Timeout errors in +translate" [Critical,Confirmed]  http://launchpad.net/bugs/30602
[02:13] <mpt_> danilos, will you have time for that this week?
[02:14] <mpt_>  * Bug 35965 (exceptions in process-upload not communicated to uploader), Critical, In Progress, malcc
[02:14] <matsubara> mpt_: stub is on vacation
[02:14] <mpt_> yay malcc
[02:14] <Ubugtu> Malone bug 35965 in soyuz "exceptions in process-upload not communicated to uploader" [Critical,In progress]  http://launchpad.net/bugs/35965
[02:14] <danilos> mpt_: I might, but any solution I plan to do is only to alleviate a problem; I can't make any promises though
[02:14] <malcc> mpt_: I was just getting ready to apologise that it's not done yet :)
[02:14] <mpt_> matsubara, ah, that shows I wasn't paying attention
[02:14] <kiko> mpt_, the PAS bug is being solved by me, I guess.
[02:14] <mpt_>  * Bug 31308 (Cannot set branch associated to a product series), Critical, Confirmed, ddaa
[02:14] <mpt_> ddaa, welcome back, any progress on 31308?
[02:14] <Ubugtu> Malone bug 31308 in launchpad-bazaar "Cannot set branch associated to a product series" [Critical,Confirmed]  http://launchpad.net/bugs/31308
[02:14] <danilos> (unless I concentrate on it before any other tasks I have)
[02:14] <matsubara> mpt_: but don't worry I will nag him about 2497 :)
[02:14] <cprov> mpt_: it may require some more discussion, see LP ML, once we decided something it should be sorted quickly.
[02:15] <mpt_>  * Bug 44214 (We need to add code to prevent POFiles being in the same path), Critical, Confirmed, carlos
[02:15] <Ubugtu> Malone bug 44214 in rosetta "We need to add code to prevent POFiles being in the same path" [Critical,Confirmed]  http://launchpad.net/bugs/44214
[02:15] <mpt_> carlos, will you have time for that this week?
[02:15] <ddaa> mpt_: sabdfl agreed on the schema change I proposed to make it simpler to fix
[02:15] <ddaa> mpt_: will probably one of the short term goals we'll define monday
[02:15] <mpt_> ok
[02:15] <carlos> mpt_: I was planning to do it this week but I'm trying to increase our automatic imports to do a full edgy import
[02:16] <mpt_> carlos, ok, you're excused :-)
[02:16] <carlos> mpt_: I guess I will have some time for it, though
[02:16] <mpt_> I think that's all of them
[02:16] <mpt_> that's all malcc 
[02:16] <malcc> mpt_: Great, thanks
[02:16] <malcc> Ok, next slot is Production and staging
[02:16] <malcc> With stub away, kiko is going to tell us about memory leaks
[02:17] <kiko> I don't know much about it. the appservers on gangotri had to be kicked yesterday.
[02:17] <kiko> I wrote an email about it, as usual.
[02:17] <ddaa> kiko: I think the technical term is "bounced"
[02:17] <kiko> elmo was kind enough to provide graphs of memory usage on gangotri
[02:17] <kiko> james suggested that update-cve may have something to do with it
[02:17] <kiko> and suggested disabling it
[02:17] <jamesh> the update-cve script was probably part of the problem (using 1.8GB of memory).  It should probably be disabled til the next rollout, or the fix cherry picked
[02:17] <jamesh> yeah
[02:18] <kiko> given that stub isn't here this week.. it would have to be requested to lifeless or a sysadmin
[02:18] <kiko> at this point I defer to SteveA deciding on what to do
[02:18] <SteveA> yeah.   if we get enough of a problem, we can restart all app servers, one by one, each day, without loss of service.
[02:18] <SteveA> while we find out what's actually wrong
[02:18] <SteveA> kiko: do you think we need to do anything before stu is back?
[02:18] <malcc> I once worked on a project where each app server needed a restart every five minutes for memory reasons. That was fun.
[02:19] <kiko> SteveA, hard to say. let me look at gangotri now.
[02:19] <kiko> jamesh, a good point though is that update-cve was /not/ running when the appserver grinded to a halt.
[02:20] <kiko> kiko@gangotri:~$ free
[02:20] <kiko>              total       used       free     shared    buffers     cached
[02:20] <kiko> Mem:       3956672    3867176      89496          0      49752    2812696
[02:20] <kiko> -/+ buffers/cache:    1004728    2951944
[02:20] <kiko> Swap:      2907724      16704    2891020
[02:20] <kiko> each appserver is at around 400MB 
[02:20] <kiko> I think we should be okay into tuesday
[02:21] <jordi> who's working on the +translations timeout, again? danilo?
[02:21] <kiko> or monday when stub's back
[02:21] <jamesh> kiko: I am sure it isn't the cause of the app server memory ballooning -- just that it could have been causing us to hit swap earlier than we might otherwise
[02:21] <jamesh> (the update-cve script, that is)
[02:21] <jordi> oh, stub apparently.
[02:21] <kiko> jamesh, mmmm. while it was running yes, but after that, you'd have a lot of memory free
[02:22] <jordi> kiko: do you know what the plan is to fix the user/+translations timeout? We talked about a redesign a while back
[02:22] <danilos> jordi: I am working on +translate timeout, kiko on +translations
[02:22] <danilos> ah, right, reassigned to stub
[02:22] <carlos> jordi: we talked about it on launchpad@ 
[02:22] <malcc> Ok, looks like our memory can take care of itself until next week
[02:23] <kiko> jordi, it's basically to cache the information, and once that is done, redesign it.
[02:23] <malcc> The other part of Production and Staging is just to ask everyone if there's anything in particular which needs rolling out next week
[02:23] <danilos> I wonder at what pace do rollouts happen in the first place?
[02:23] <jordi> kiko: okay, I guess I need to intervene at the redesign phase, as I have some feedback from users when we asked them
[02:23] <mpt_> Should the changes to person pages for people who haven't used Launchpad be cherrypicked?
[02:23] <danilos> there hasn't been any in like last two weeks?
[02:23] <kiko> malcc, I think we should do a full rollout (based on today or so) on tuesday
[02:24] <ddaa> malcc: got some much expected branch ui changes in review now
[02:24] <carlos> kiko++
[02:24] <kiko> danilos, we were rolling out weekly. the past month we've done it bi-weekly and now tri-weekly
[02:24] <cprov> malcc: soyuz has, as you know, but we need to test them properly before it, we depend on "soyuz test env setup"
[02:24] <SteveA> mpt_: not until stu gets back, and if the rollout will be monday or tuesday, then not at all
[02:24] <ddaa> it would be great to have to have it rolled out quickly. It allows people to rename and reassign branches.
[02:24] <danilos> kiko: ah, ok, thanks for the info
[02:24] <kiko> cprov, but no database changes should break production, anyway.
[02:24] <ddaa> but it's not yet merged yet
[02:24] <malcc> cprov: Yes, drescher rollouts are hanging behind the main rollout at the moment, for anyone who didn't know
[02:24] <kiko> cprov, so rolling out to gangotri and friends should be okay, no?
[02:25] <kiko> mmmmm
[02:25] <kiko> sabummerthat
[02:25] <cprov> kiko: yes, good point, we should not block the rest of the team
[02:25] <malcc> kiko, cprov: Yes, the latest Soyuz patches should be able to go out to the appservers without any carnage
[02:25] <malcc> Anything else on rollouts?
[02:25] <kiko> malcc, with one caveat. if something /did/ change in the database we may get some bustage in soyuz.
[02:25] <kiko> not in the publishing tables but elsewhere
[02:26] <kiko> I don't know where but some of our content classes... you know.
[02:26] <cprov> kiko: cherrypick it in drescher ... as usual
[02:26] <malcc> kiko: Yes, we need to be careful
[02:26] <ddaa> kiko: Person is usually the culprit
[02:26] <kiko> cprov, you said it my man!
[02:26] <kiko> ddaa, it's a common offender, because it's used by everybody.
[02:26] <kiko> I'll look at DB patches pending rollout
[02:26] <ddaa> The same issue affects importd btw, luckily it's not changed all that often.
[02:27] <kiko> apparently there's nothing that changed in the DB for this rollout
[02:27] <kiko> well, two minor changes, constraint-related.
[02:27] <ddaa> (importd is routinely weeks or months behing rocketfuel)
[02:27] <malcc> Ok, let's move on
[02:27] <malcc> Which means it's time for... Launchpad 1.0 status reports!
[02:27] <malcc> Who's got one?
[02:27] <ddaa> importd-bzr-native: on track, ddaa needs to focus on arch-support excision soon
[02:27] <ddaa> bzr-roundtrip-svn: target postponed (not 1.0), discussion on how to make bzr-svn acceptable to importd in progress.
[02:27] <ddaa> supermirror-smart-server: spiv and mpool currently working hard on that one. I'm not clear on whether we are on track to have it deployed on target.
[02:28] <salgado> Question Tracker 1.0
[02:28] <salgado> ---------------------------------
[02:28] <salgado> - SupportTrackerKarma is implemented and already in rocketfuel
[02:28] <salgado> - Localization has been dropped as a 1.0 target.  Salgado finished rearranging it into other specs so that we can decide what will be a 1.0 goal and what's not.  Needs input from SteveA.
[02:28] <salgado> - New Workflow: Still waiting for kiko's review of the spec. Search on creation was reviewed and should land soon.
[02:28] <salgado> - Support Tracker Views: Waiting completion of New Workflow.
[02:28] <salgado> Random Things 1.0
[02:28] <salgado> -------------------------------
[02:28] <salgado> - KarmaContext is implemented and in production.
[02:28] <salgado> - PersonCreationRationale has been started and has good progress.
[02:28] <salgado> - DirectPersonRegistration has a tricky issue blocking its implementation, so it needs discussion.
[02:28] <bradb> Malone 1.0:
[02:28] <danilos> Rosetta 1.0:
[02:28] <danilos> - opening edgy for translation: DONE!
[02:28] <danilos> - firefox import/export: good progress (integration of import in process, starting on export)
[02:28] <danilos> - oo import/export: blocked on firefox
[02:28] <danilos> - translation review: good progress
[02:28] <bradb> -----------
[02:28] <bradb> Tags: Landed fixes that were in review last during last status report.
[02:28] <bradb> Documentation: Not started.
[02:28] <bradb> Keeping Bugs Concise: Collapsing comments will likely not be a 1.0 goal. kiko has a branch on the way for collapsing the original description behind a link (maybe landed?)
[02:28] <danilos> - essential docs: sabdfl assigned to danilos, need to discuss with jordi
[02:28] <bradb> Release management: Went through review. Small SQL cleanups sent off to the DBA (currently underwater) for review.
[02:28] <danilos> - poimports: not started (checks not to upload wrong language PO file using "too many changes" check)
[02:28] <bradb> Guided filebug: Good progress for time spent on it. One or two more days of work + review.
[02:28] <danilos> - ui fixes: not started
[02:28] <danilos> - outstanding issues: none
[02:29] <ddaa> yay muxed progress reports!
[02:29] <malcc> Malone and rosetta punching it out there! :)
[02:29] <danilos> rosetta wins with a knock-out ;)
[02:29] <bradb> heh
[02:29] <mpt_> I'll sort it all out in the log
[02:30] <jordi> go danilos, kick those maloners :)
[02:30] <malcc> Soyuz 1.0: We've identified a new test process to prevent archive breakage and heart attacks, which we're working on. We had good design progress towards PPA last week. We still don't have a *proper* 1.0 status report though :)
[02:30] <malcc> Ok, is that all of them?
[02:30] <malcc> Then... Sysadmin requests.
[02:30] <ddaa> RT 16533: Please give "sudo -u supermirror" rights to user "david" on vostok.
[02:31] <SteveA> ddaa: what does this block?
[02:31] <ddaa> SteveA knows that one. Still had no sysadmin feedback.
[02:31] <kiko> bradb, what about upstream forwarding?
[02:31] <kiko> or is that not 1.0
[02:31] <ddaa> SteveA: not blocking anything ATM, since the sftp-mirroring problem has been resolved
[02:31] <cprov> malcc: we want space in mawson, which RT ? 
[02:32] <SteveA> ddaa: okay, so I won't hassle the admins about it
[02:32] <malcc> cprov: The one for db backup cleaning was done already, we have much space now
[02:32] <cprov> malcc: good, thanks 
[02:32] <malcc> Any more?
[02:32] <bradb> kiko: !1.0
[02:32] <malcc> 5
[02:32] <malcc> 4
[02:32] <malcc> 3
[02:32] <malcc> 2
[02:32] <malcc> 1
[02:32] <malcc> !
[02:32] <malcc> Ok
[02:32] <malcc>  * Timely bug triage (bradb)
[02:32] <kiko> bradb, would be nice to get done before 1.0, and I'm pretty sure that BjornT can do it. or is BjornT working on something else?
[02:33] <kiko> bradb, BjornT: I don't want all that spec/design work to be lost because it fell out of date..
[02:33] <bradb> kiko: You'd have to ask him
[02:33] <bradb> anyway, TBT...
[02:33] <bradb> I've found it pretty tricky to keep up with bugmail
[02:34] <BjornT> kiko: i'll have to look at the spec to see if everything can be done before 1.0. at leaste parts of it will certainly get done.
[02:34] <bradb> e.g., right now, I have 2485 bugmail to go through
[02:34] <bradb> so, I thought I'd raise the issue for discussion at the meeting. anyone else finding bugmail a bit overwhelming?
[02:34] <matsubara> me
[02:34] <SteveA> does our bugmail thread well?
[02:34] <bradb> I'm wondering, for example, if Launchpad needs a bugmaster
[02:34] <matsubara> SteveA: yes
[02:34] <danilos> me as well
[02:34] <SteveA> bradb: maybe you could read it threaded?
[02:34] <bradb> SteveA: yeah
[02:34] <bradb> SteveA: that's a given, yeah :)
[02:34] <danilos> I'd prefer to have separate rosetta@ bugmail
[02:35] <salgado> what I do it to only read new bugmail everyday and then subscribe to the bugs to which I have interest or in which I may help
[02:35] <spiv> I've started procmailling my bugmail by product.
[02:35] <kiko> danilos, it's very easy to separate that. just filter on X-Launchpad-Bug.
[02:35] <matsubara> I use this bookmark to help on the initial triage: https://launchpad.net/projects/launchpad-project/+bugs?field.searchtext=&orderby=-datecreated&search=Search&field.status%3Alist=Unconfirmed&field.status%3Alist=Confirmed&field.status%3Alist=In+Progress&field.status%3Alist=Needs+Info&field.status%3Alist=Fix+Committed&field.importance%3Alist=Untriaged&field.assignee=&field.owner=&field.omit_dupes=on&field.has_patch=&field.has_no_pa
[02:35] <matsubara> ckage=&start=0&batch=300
[02:35] <danilos> though, I should probably filter on X-Launchpad-Bug: product=rosetta
[02:35] <salgado> this way I get bugmail for these ones on my inbox, and make sure we always read them
[02:35] <kiko> danilos, yes.
[02:35] <ddaa> same thing, I have Thunderbird filter rules that sort mail by product using the X-Lauchpad-Bug header
[02:35] <kiko> salgado, I do the same.
[02:36] <ddaa> and mark all bugmail except the launchpad and launchpad-bazaar stuff as read immediately
[02:36] <bradb> danilos: you'll want the launchpad bugs too
[02:36] <BjornT> it's not all about reading bug mail, though. an important part is triaging bugs, we are bad at doing that today.
[02:36] <bradb> yeah, that's what i'm really getting at.
[02:37] <mpt_> matsubara does some, I do some
[02:37] <bradb> like, providing a response time of 48-72 hours, /max/, per report
[02:37] <mpt_> I get the feeling it's not particularly thorough, though
[02:37] <danilos> bradb: yeah, but I need to put higher priority on reading rosetta ones
[02:37] <ddaa> bradb: that means things like coordinating vacations and sprints
[02:37] <SteveA> I think this is getting off-topic
[02:37] <BjornT> so even though some say that they handle bug mail today, we still need to do better. it'd would be good if we came up with some guidelines, and made that that each part of launchpad has someone responsible for triaging the bugs.
[02:38] <bradb> ddaa: yeah. that's why i'm wondering if we need a bugmaster.
[02:38] <ddaa> bradb: I'm not convinced it's the solution to timely bug triage
[02:38] <malcc> Yes, and we're falling a bit late
[02:38] <flacoste> BjornT: +1
[02:38] <malcc> Can we take this discussion out of the meeting for afterwards?
[02:38] <bradb> er, i guess
[02:39] <malcc>  * Testing bzr release candidate (Steve)
[02:39] <SteveA> so
[02:39] <SteveA> I'd like everyone to try out the RC for the new bzr release
[02:40] <SteveA> it should work okay, and be faster than the one we're using
[02:40] <ddaa> Cool!
[02:40] <SteveA> i'll mail the list with simple instructions on how to get it, after this meeting
[02:40] <ddaa> How do we get it?
[02:40] <jamesh> should we use particular packages of it?
[02:40] <jamesh> okay
[02:40] <malcc> Great, thanks SteveA
[02:40] <SteveA> there will be a line in /etc/apt/sources.list
[02:40] <SteveA> and a couple of commands to run
[02:40] <ddaa> And _don't press the red button_!
[02:40] <malcc> :)
[02:40] <SteveA> please try it out, and send feedback to the launchpad list, cc mpool
[02:41] <SteveA> that is all
[02:41] <salgado> do we have the pqm-submit plugin for this version too?
[02:41] <malcc> SteveA: Thanks
[02:41] <malcc>  * (other items)
[02:41] <malcc> matsubara: Did you have one?
[02:41] <matsubara> I proposed the infra tag (https://help.launchpad.net/TaggingLaunchpadBugs). SteveA could you take a look? kiko doesn't like the idea of assigning bugs to teams. Is there any rationale to assign some bugs to lp-infrastructure team apart from grouping them?
[02:41] <kiko> matsubara, SteveA: assignees should be people I can hassle for doing things.. assigning to a team dilutes responsibility and in the end the fix doesn't get done.
[02:42] <ddaa> kiko++
[02:42] <SteveA> I see what you mean.  Although, that is more of an issue with having an appropriate process rather than assigning to a team per se
[02:42] <SteveA> for example
[02:42] <kiko> (IKWYM, but I feel it certainly adds to the problem)
[02:42] <SteveA> I can imagine a process where it gets assigned to a team, and then at a team meeting, team bugs are assigned to individuals
[02:42] <kiko> I agree. but we do not have such a process. :)
[02:43] <jordi> I'd like to request that we start talking about how to market launchpad (and rosetta specifically in my case), so if kiko/steve want to have a meeting about it. I'm having trouble convincing bigger projects to move on, we had a small chat about it in #canonical today about it
[02:43] <mpool> salgado: yes, pqm-submit should be updated
[02:43] <kiko> jordi, if you want to talk about it, talk to me!
[02:43] <jordi> I can post to the list with some background
[02:43] <jordi> kiko: will do then!
[02:43] <kiko> jordi, I've been talking about this for a while now
[02:43] <kiko> and doing some of it now
[02:43] <kiko> so it'll be cool to have help
[02:43] <kiko> and we can tag-team it
[02:43] <jordi> kiko: great, let's have a chat later on
[02:43] <malcc> Great
[02:44] <malcc> Any more on those issues, or any more issues?
[02:44] <ddaa> Running late!
[02:44] <SteveA> matsubara: I'm fine with having an "infrastructure" tag to mark bugs that are to do with infrastructure.
[02:44] <SteveA> I don't think this in itself solves the problem of certain bugs not getting attention.
[02:44] <matsubara> SteveA: ok, I'll update the wiki ( but I don't like big tags neither my wrists :)
[02:44] <SteveA> and I dont' think a tag is a good way to assign responsibility
[02:44] <malcc>  * Keep, Bag, Change
[02:45] <mpt_> BAG: the "BLOCKED:" line in meetings if you're not blocked
[02:45] <malcc> ddaa: Yes, noted, let's finish up quickly
[02:45] <jordi> mpt_: +1!
[02:45] <SteveA> mpt_: I like that, because it means people need to say "I am not blocked" explicitly.
[02:45] <ddaa> mpt_: -1
[02:45] <ddaa> SteveA: +1
[02:45] <malcc> Ok, let's keep that for now then
[02:45] <danilos> ddaa: (this -1+1 thing will make writing summaries easier for mpt ;))
[02:45] <SteveA> but, mpt_, talk with me about this after the meeting, if you have a better idea
[02:45] <malcc> Anything else?
[02:45] <malcc> 5
[02:45] <malcc> 4
[02:45] <malcc> 3
[02:45] <malcc> 2
[02:45] <malcc> 1
[02:46] <malcc> 0
[02:46] <malcc>  * Three sentences
[02:46] <flacoste> DONE: Landed tt-buglinktarget, worked on fixing bug 52671, improved tt-search based on james's review
[02:46] <flacoste> TODO: Land tt-search, finish fix for support contacts, work on SupportTrackerWorkflow implementation
[02:46] <flacoste> BLOCKED: still waiting for kiko's review/approval of the spec
[02:46] <Ubugtu> Malone bug 52671 in launchpad-support-tracker "Support contact implementation shortcomings" [High,Confirmed]  http://launchpad.net/bugs/52671
[02:46] <mpt_> DONE: Returned to NZ, Net problems, PersonCreationRationale, bug fixes
[02:46] <ddaa> DONE: vacation, catchup, merging outstanding branches, bzr-svn discussion
[02:46] <ddaa> TODO: more catchup, more work on outstanding code, new short term targets not yet decided (next launchpad-bazaar meeting)
[02:46] <ddaa> BLOCKED: no
[02:46] <mpt_> TODO: UI work, general subscriptions spec, outages spec, bug fixes
[02:46] <mpt_> BLOCKED: no
[02:46] <jordi> DONE: rosetta licensing meeting with the team and steve; lots of email / mailing lists, some imports
[02:46] <spiv> DONE: reviews, progress on bzr smart server
[02:46] <spiv> TODO: snowboarding (on holiday next week)
[02:46] <spiv> BLOCKED: no
[02:46] <cprov> DONE: recover from sprint, soyuz navigation research, soyuz test enviroment setup, lot of discussion P-a-s & ArchveRework
[02:46] <cprov> TODO: finish soyuz test setup and hopefully *safe* land soyuz cleanups & ArchiveRework
[02:46] <cprov> BLOCKED: none
[02:46] <malcc> DONE: Finished sprint, started setting up test system to test sprint results.
[02:46] <BjornT> DONE: bug fixes. code reviews. some more work on bug forwarding workflow.
[02:46] <malcc> TODO: Finish testing system, test sprint results, land. Finish 35965 fix.
[02:46] <malcc> BLOCKED: For proper dogfood testing, on a recent production db snapshot.
[02:46] <BjornT> TODO: fix bugs. code reviews. finish off product-bugtracker branch.
[02:46] <BjornT> BLOCKED: no
[02:46] <matsubara> SteveA: we're not using tags to assign responsability, just grouping bugs. Responsability can be sorted in the team meeting.
[02:46] <danilos> DONE: pqm-submit 3986, sampledata updates, discussions, firefox import work, user support, rosetta imports started
[02:46] <danilos> TODO: bug 30602, ff-export and integration, bug fixing, meeting with stub on rosetta data model
[02:46] <danilos> BLOCKED: no
[02:46] <Ubugtu> Malone bug 30602 in rosetta "Timeout errors in +translate" [Critical,Confirmed]  http://launchpad.net/bugs/30602
[02:46] <salgado> DONE: Landed the GPG/SSH fixes, code review, started implementing PersonCreationRationale and cleaned up lots of code on the way
[02:46] <salgado> TODO: Finish the implementation of PCR, code review, start writing the infrastructure to allow the shipit frontpage to be customized through a web UI.
[02:46] <salgado> BLOCKED: No
[02:46] <bradb> DONE: Worked on guided filebug. Release management review. Bug fixes. Loads of bugmail/triage. Wrote UnsubscribingIndirectBugSubscribers.
[02:46] <bradb> TODO: Release management DBA review. Small tweaks. Put guided filebug up for review.
[02:46] <bradb> BLOCKED: stub on reviewing Release Management DB patch.
[02:46] <matsubara> DONE: oops report analysis, triage, fixed #58222
[02:46] <matsubara> TODO: more of the same
[02:46] <matsubara> BLOCKED: no
[02:46] <mpool> DONE: some smart server, strategic planning, hiring
[02:46] <mpool> BLOCKED: no
[02:46] <jordi> TODO: product/edgy import queue, KDE email
[02:46] <jordi> BLOCKED: no
[02:46] <SteveA> DONE: management, ui devo infrastructure, code review
[02:46] <SteveA> TODO: the same
[02:46] <SteveA> BLOCKED: no
[02:46] <kiko> DONE: soyuz hacking, catching up on email, spec reviews
[02:46] <jamesh> DONE: code reviews, product-release-finder fixes, update-cve fixes, launchpadformview fixes, other bug fixes
[02:46] <jamesh> TODO: code reviews, better url handling for LP, more PRF stuff if necessary, more Python tracker stuff as necessary.
[02:46] <jamesh> BLOCKED: no
[02:46] <mpool> TODO: finish plans, conference papers, docs, smart server, hiring, lots more
[02:47] <kiko> TODO: launchpad report, spec reviews, more email catchup, try and get some of my old bugs done
[02:47] <kiko> BLOCKED: I'd like elmo or infinity to review my PAS discussion and proposals
[02:47] <carlos> DONE: TranslationReview, debugged koffice problems in dapper, Edgy translations
[02:47] <carlos> TODO: TranslationReview, bug #58168 and other Edgy imports bugs
[02:47] <carlos> BLOCKED: no
[02:47] <Ubugtu> Malone bug 58168 in rosetta "Missing upstream translations for ktorrent-2.0.1" [High,Confirmed]  http://launchpad.net/bugs/58168
[02:47] <malcc> Is that everyone?
[02:48] <malcc> 5
[02:48] <malcc> 4
[02:48] <malcc> 3
[02:48] <malcc> 2
[02:48] <malcc> 1
[02:48] <malcc> 0
[02:48] <malcc> Ok great
[02:48] <malcc> Thanks everyone, apologies for three minutes overtime
[02:48] <malcc> MEETING ENDS
[02:48] <jordi> awesome, first meeting in ages where I haven't been forced to walk away from my chair
[02:48] <carlos> ;-)
[02:48] <carlos> later!
[02:48] <jamesh> forced?
[02:48] <jordi> laters
[02:48] <bradb> So, anyone interesting in talking triage/bug report response times? :)
[02:48] <bradb> interested, even
[02:49] <danilos> jordi: so you were able to roll on the wheels? :)
[02:49] <flacoste> jamesh: when do you think you'll have time to review my new version of tt-search?
[02:49] <SteveA> thank you malcc 
[02:49] <jordi> danilos: er, what? :)
[02:49] <danilos> jordi: you know, chairs with wheels; I'd say wheel-chairs, but they're something else in English :)
[02:50] <jamesh> flacoste: I'll send some more comments later on tonight
[02:50] <jordi> danilos: hehehe
[02:50] <flacoste> jamesh: ok, thanks
[02:50] <jordi> no, actually I do that a lot :)
[02:50] <flacoste> kiko: do you think you'll have time to comment on the spec today?
[02:50] <jordi> (moving on my chair around the place ;)
[02:50] <BjornT> bradb: i'd be interested
[02:50] <kiko> flacoste, yes.
[02:50] <mpt_> bradb, one way would be to implement the suggestion I made of publicizing the average response time whenever you report a bug
[02:50] <jordi> but today, oh man, I was left alone for 47 minutes.
[02:50] <jamesh> kiko: I did up a script to fix the "bug NNN" references in the old bugs we imported from bugzilla
[02:50] <flacoste> kiko: great!
[02:50] <danilos> jordi: yeah, I figured: you didn't have to walk away this time, you just rolled around :P
[02:50] <mpt_> bradb, that wouldn't help directly, but it would be a great motivator :-)
[02:50] <kiko> jamesh, AH! ROCK /ON?!
[02:51] <kiko> awsome
[02:51] <kiko> bradb, yeah, I'm interested, I've been talking about this with matsubara 
[02:51] <bradb> mpt_: ooooo! that's an interesting approach...
[02:51] <jamesh> kiko: I ran it on demo.launchpad.net, so you can compare
[02:51] <kiko> essentially though I think this is matsubara's job, though.
[02:51] <mpt_> yes, matsubara does a good job
[02:52] <kiko> mpt_, bradb: so I think we should discuss and come up with something that allows matsubara to do a better job at triaging, and perhaps giving good metrics is part of that.
[02:52] <jamesh> kiko: the script is not that clean, but I plan to clean it up when repurposing it for the Python SF bug import
[02:52] <mpt_> especially with errors
[02:52] <bradb> kiko: right
[02:52] <kiko> jamesh, okay. do you have an example bug? 
[02:52] <bradb> So, first, does a goal of 48-72 hours seem a reasonable first response time?
[02:52] <BjornT> kiko: i don't think that matsubara can handle all the bugs by himself, though.
[02:53] <jamesh> kiko: https://launchpad.net/products/malone/+bug/42884 vs. https://demo.launchpad.net/products/malone/+bug/42884
[02:53] <Ubugtu> Malone bug 42884 in malone "Duplicate markings from bugzilla.ubuntu.com shouldn't link to irrelevant bugs" [Medium,Confirmed]  
[02:53] <mpt_> kiko, producing good Bugs front pages will help with that (so matsubara won't need to keep fancy bookmarks for things like "all Untriaged bugs in Launchpad")
[02:53] <kiko> bradb, yes.
[02:53] <kiko> BjornT, I think either he has to or he needs to build a triage community to work with him
[02:53] <kiko> I don't think you guys should be doing initial triage..
[02:54] <bradb> second, speaking of matsubara then: 1. do we need a "bugmaster" to achieve this, and 2. if so, is matsubara officially our bugmaster?
[02:54] <bradb> i.e. is matsubara the simon law of launchpad?
[02:54] <kiko> jamesh, /awesome/!
[02:54] <kiko> bradb, yes to both questions.
[02:54] <mpt_> bradb, 37926
[02:54] <mpt_> bug 37926
[02:54] <Ubugtu> Malone bug 37926 in malone "Manage expectations about newly-reported bugs" [Medium,Confirmed]  http://launchpad.net/bugs/37926
[02:55] <kiko> jamesh, that's very good work -- even more so that you dropped the link to the bugtracker/ url 
[02:55] <bradb> mpt_: heh, that's too cool
[02:55] <jamesh> kiko: the script actually uses that URL to work out where the numbers it needs to replace are
[02:55] <bradb> so, one thing that strikes me is that maybe sfllaw can give matsubara some ideas on drinking from the firehose
[02:56] <kiko> bradb, yeah. though I think sfllaw basically delegates a lot of his work.
[02:56] <kiko> I don't think matsubara will get a lot of help
[02:56] <kiko> but perhaps 
[02:56] <bradb> could be
[02:56] <BjornT> kiko: i'd be happy for matsubara to triage all the bugs, but then i think we should define exactly what's expected by him. at the moment a lot of bugs are untriaged, should we nag matsubara about it, or triage them ourself?
[02:56] <kiko> BjornT, the former.
[02:56] <kiko> we don't get /that many/ new bugs
[02:56] <kiko> less than 30 a day last I checked
[02:56] <flacoste> kiko: what about bug we report?
[02:57] <bradb> another thing, i think it would be nice if we had reports that everyone could see, that showed Launchpad's bug triage response time, and then a comparison between each of the apps
[02:57] <kiko> flacoste, bugs /we/ report?
[02:57] <jamesh> kiko: fixing bug references in SF imported bugs would work similarly: add an ugly unique blob to bug references in the imported comments, and then post process it to replace the correct bug numbers
[02:57] <kiko> jamesh, we're missing the big blob now, then
[02:57] <kiko> flacoste, well, you can confirm and triage it yourself, or leave it to be processed as part of daily triage.
[02:57] <flacoste> kiko: when I report a bug, should I triage it, or let mastubara do it?
[02:57] <jamesh> kiko: yeah.  I haven't implemented this for SF import yet.
[02:58] <kiko> flacoste, either is fine. you can triage it if you are very sure about it -- otherwise leave it to the qa team.
[02:58] <BjornT> kiko: true. but we still have a lot of untriaged bugs, so something is not working.
[02:58] <flacoste> makes sense
[02:58] <jamesh> kiko: it does need to be a two step process though, since you don't know what the LP bug numbers will be til the import is complete ...
[02:58] <kiko> jamesh, what about this: https://demo.launchpad.net/products/malone/+bug/16000
[02:58] <Ubugtu> Malone bug 16000 in evolution "evolution crashes when trying to forward email with strange subject encoding" [Medium,Fix released]  
[02:58] <kiko> BjornT, I need to talk to matsubara about this, but essentially, incoming bug triage hadn't been an explicit priority/activity, and now it is becoming one.
[02:59] <jamesh> kiko: the bug number in question wasn't an ubuntu bugzilla bug ID
[02:59] <jamesh> kiko: my script just left those as is
[02:59] <mpt_> flacoste, on a related issue I came across a bug report today asking for people to be prevented from confirming their own bug reports
[02:59] <bradb> btw, not ragging on matsubara here, I think he does a fantastic job on the oops reports, and has triaged a lot of bugs, but the fact that I also found quite a few bugs that hadn't yet been triaged lead me to wonder where the line on his responsibilities was drawn
[02:59] <kiko> jamesh, it wasn't? what do you mean?
[02:59] <kiko> bradb, it's just a matter of sorting out the assignment, as I said above.
[02:59] <mpt_> anyway, bedtime for me
[02:59] <jamesh> kiko: the user has written "** Filed upstream as bug #300679"
[03:00] <bradb> kiko: what about the reports idea?
[03:00] <kiko> oh. in evo bugzilla.
[03:00] <kiko> bradb, that's a fab idea.
[03:00] <bradb> kiko: in LP, perhaps?
[03:00] <jamesh> kiko: when we imported the bug into LP, we added the URL, but it was never an Ubuntu bug number
[03:00] <bradb> i.e. so it's a feature other projects, like Ubuntu, can use
[03:01] <BjornT> kiko: i understand, and i'm certainly not i'm blaming matsubara for it. it'd be good if you discussed with matsubara, how the triage processs should work. then you create a wiki page, so that it's clearly defined, and so that we can comment on it.
[03:02] <bradb> (BTW, I will summarize all discussion to the mailing list, when we're done)
[03:04] <bradb> and/or a wiki page, yeah
[03:05] <bradb> mpt_: I could see not confirming one's own reports making sense for users that don't smell like developers, i.e., they're not bug contacts, assignees, or drivers of the affected software.
[03:05] <bradb> and only restricting the reporter on that basis
[03:06] <BjornT> matsubara: do you have any immediate suggestions on how to improve malone, in order to make your job easier?
[03:06] <matsubara> BjornT: just added a comment to bug 37926
[03:08] <bradb> matsubara: do you still have that mail from orkut/
[03:08] <matsubara> yes but it's portuguese. :)
[03:08] <matsubara> s/it's/it's in/
[03:08] <bradb> ah :)
[03:08] <matsubara> bradb: I can send it to you if you want
[03:09] <bradb> I am not a polyglot, unfortunately :/
[03:09] <matsubara> BjornT: adding a tags and duplicate command to the email interface would help too
[03:09] <matsubara> bradb: you can use the fish
[03:09] <matsubara> :)
[03:09] <bradb> heh
[03:09] <sivang> bradb: what's so interesting in an orkut email? :)
[03:10] <bradb> sivang: bug triaging technique
[03:10] <sivang> bradb: eh :-) I didn't know orkut can be used for that as well
[03:10] <bradb> orkut is many things to many people
[03:10] <kiko> to kiddie porn collectors in particular
[03:11] <bradb> !
[03:11] <bradb> Anything else to add before I capture this discussion on the mailing list?
[03:11] <bradb> 5
[03:11] <bradb> 4
[03:11] <bradb> 3
[03:11] <bradb> 2
[03:12] <bradb> 1
[03:12] <bradb> 0!
[03:12] <bradb> (fin)
[03:12] <bradb> right, gotta get ready to head to the office, will summarize when i get there
[03:51] <matsubara> bradb, BjornT: sent you the message from orkut (roughly) translated.
[04:34] <malcc> With Robert sick and Stuart away, is there anybody else who can provide a copy of an up-to-date launchpad production snapshot on mawson?
[04:35] <malcc> We're not blocked on it, we can continue to try out our testing based on an older db, but we'll likely be blocked in due course if nothing moves
[04:39] <salgado> malcc, I guess one of the people with access to staging (carlos, kiko, ??) should be able to find an existing dump there (used to build the staging db) or even generate a new one from staging
[04:39] <malcc> salgado: Thanks, good idea.
[04:42] <kiko> malcc, let me look.
[04:47] <kiko> salgado, carlos: do you know where db dumps are kep?
[04:48] <kiko> malcc, found it.
[04:48] <salgado> kiko, no idea. :(
[04:48] <kiko> it's not small
[04:48] <kiko> malcc, where do you want it copied?
[04:48] <kiko> -rw-r--r-- 1 postgres postgres 12479252859 Aug 31 01:33 launchpad_prod.dump
[04:49] <malcc> kiko: Wow, that isn't small
[04:49] <malcc> kiko: Anywhere on mawson I can read it from, eg ~launchpad would do
[04:50] <kiko> one sec.
[04:50] <kiko> for reference, malcc, it's in /var/lib/postgresql
[04:50] <malcc> kiko: Thanks
[04:50] <kiko> malcc, 8:17 ETA, on mawson/~kiko.
[04:50] <kiko> salgado, thanks for the idea, you da man
[05:02] <kiko-fud> malcc, copy finished, enjoy the 12gig file!
[05:02] <malcc> kiko-fud: Thanks, I will :)
[05:07] <janimo> ddaa: hi, any new insights into why some packages may fail to import to bzr? (ex: xfprint4)
[05:07] <ddaa> REPORT request failed on '/svn/xfce/!svn/bc/19952/xfprint/trunk/libxfprint' 
[05:07] <ddaa>  '/svn/xfce/!svn/bc/19952/xfprint/trunk/libxfprint' path not found
[05:07] <ddaa> Still no idea of what is causing this problem.
[05:08] <janimo> did you see thiss happen for other upstreams as well besides the xfce repo?
[05:08] <ddaa> yes, https://svn.participatoryculture.org/svn/dtv/trunk/tv
[05:08] <janimo> if not it may be some unusual setup
[05:08] <ddaa> on Launchpad https://launchpad.net/products/democracy/trunk
[05:09] <ddaa> janimo: I'll make you the contact for xfprint4 import failure
[05:09] <janimo> ah ok
[05:09] <janimo> ddaa: what will that mean? do I get the error messages?
[05:10] <janimo> what is weird that one out of 6 products of the same svn repo worked
[05:10] <ddaa> It means I'll tell you when it works, or when I need some more help.
[05:10] <ddaa> mh, just got a similar problem with xfwm4...
[05:11] <ddaa> previously it failed because of "OSError: [Errno 12]  Cannot allocate memory" on os.fork()
[05:11] <janimo> ddaa: also xfdesktop4 thunar and xfce4-session IIRC
[05:11] <ddaa> It's almost certainly some well known svn feature that cscvs just does not know how to deal with
[05:12] <ddaa> janimo: your memory is remarkable
[05:12] <janimo> ddaa: well I have only registered 6 products to import (the ones are core xfce apps) so it's hard to forget :)
[05:12] <janimo> but some may have got stuck in Testing while others outright failed
[05:13] <ddaa> FYI, my notes are visible there: https://help.launchpad.net/VcsImportRequests
[05:15] <janimo> is this a modified and closed cscvs or a free one?
[05:19] <carlos> kiko-fud: no idea, I only know how to update staging's code 
[05:19] <carlos> no idea about the DB mirroring
[05:21] <ddaa> janimo: heavily modified, still closed
[05:22] <ddaa> We will open it eventually (sabdfl agreed to let me do it when I think it's right)
[05:22] <ddaa> but there's still some changes we need to do first. Most importantly, remove all the Arch support code that we _really_ do not want to have to support.
[05:23] <ddaa> janimo: I'm quite keen at releasing this code as this will allow community members help fix this sort of problem.
[05:23] <janimo> ddaa: nice
[05:24] <ddaa> janimo: please just do not set up an alternative free imports service with that code, or sabdfl will make me pay for it dearly ;)
[05:25] <janimo> ddaa: I am not sure soemone would be crazy enough to take on such a big task
[05:25] <ddaa> Well, as sabdfl says, the internet is a bell curve.
[05:26] <jamesh> ddaa: if it helps, the problem revision for smartpm appears to do a directory move trunk/epm/loaders to trunk/epm/backends
[05:26] <ddaa> I'm pretty sure somebody will do it eventually, even if just to bother us.
[05:26] <jamesh> ddaa: which kind of matches the "'/!svn/bc/28/trunk/epm/backends' path not found" error, since the directory didn't exist in the previous revision
[05:26] <janimo> yes, but it's all about users. They can do it but users will be hard to convince (it's hard enough with LP) to start using it
[05:27] <ddaa> jamesh: now that's very interesting
[05:27] <janimo> there are rosetta lookalikes (before rosetta was done) but I don;t think they have as many users
[05:27] <ddaa> jamesh: it might just be the same error logic that cause the "ClientError: File not found" error.
[05:28] <jamesh> ddaa: maybe.
[05:28] <ddaa> jamesh: please leave me ignorant for now, diagnostic import problems is a big time sink and need to keep other stuff going :)
[05:29] <jamesh> ddaa: should I add a note to the wiki page then?
[05:29] <janimo> ddaa: I'd ask for a prerelease tarball just for provate debugging of this xfce svn problme but I am afraid it would take a lot of time for me to set it up and grok the code to be able to debug it
[05:29] <janimo> I haven;t used cscvs before
[05:29] <ddaa> jamesh: more than welcome, please add a note below the corresponding section title
[05:29] <janimo> s/provate/private/
[05:30] <ddaa> janimo: if you willing to sign a NDA, I can escalate your request
[05:30] <ddaa> and I never say that csvs was easy. It's neither easy nor pretty. But there's a big difference between "impossible" and "difficult".
[05:30] <janimo> ddaa: so the expected time before clean-up arch stuff and release to piblic is longer than it'd take to sign and send paperwork?
[05:31] <ddaa> There's no expected time yet.
[05:31] <ddaa> So the paperwork would clearly be the safe option.
[05:31] <janimo> right, but if it's something I need to spend a few days on before actually being able to nail down this problem I don;t have that much time unfortunately :(
[05:32] <ddaa> Mh, not that much. I'll give you all the help you need. Some people (admittedly with unordinately wide and bald foreheads) have been seen to fix issues in cscvs in a few hours. In particular the svn support code does not quite break your brain.
[05:33] <ddaa> I'm specifically thinking of jamesh and Kamion
[05:33] <ddaa> Which are slightly superhuman programmers.
[05:33] <ddaa> s/Which/Who/
[05:33] <dsnopek> Hello!
[05:34] <janimo> my forehead is not really wide nor bald.hmm.
[05:35] <jamesh> neither is mine!
[05:36] <bradb> i think jamesh and that reporter at the daily planet might be the same guy
[05:45] <Ubugtu> New bug: #58361 in launchpad "Product portlet has inconsistent links for Registrant, {Security,Bug} contact." [Low,Confirmed]  http://launchpad.net/bugs/58361
[05:45] <ddaa> janimo: can you give me a boolean value for whether you would sign a NDA to gain access to cscvs? (not sure it's going to work, but I do not want to bother the top execs with that unless I have at least a verbal commitment)
[05:46] <dsnopek> Can anyone tell me how long an upstream import will be status "Testing" ?
[05:46] <janimo> ddaa: the reason I would say no is because I am interested in debugging I cannot know for sure if after 5 minutes of lookig at it I do not run away screeming
[05:47] <janimo> ddaa: so it may be that I'd just cause lost time for you and the execs for nothing
[05:47] <ddaa> dsnopek: currently, until I give it some love. Will do right now.
[05:47] <dsnopek> ddaa:  Thanks!
[05:47] <ddaa> Then, until the test import completes or fail.
[05:47] <janimo> it's different when you can 'sniff' around a codebase before knowing you are likely to work on it..
[05:48] <janimo> ddaa: so me signing an NDA (which I have nothing againt in this case) would mean a 'soft' commitment which I cannot make
[05:48] <ddaa> janimo: I'm more interested in your willingness to follow on the paperwork and at least give it a try, than in getting concrete results
[05:49] <ddaa> in any case may have some interesting feedback
[05:49] <ddaa> * case you may
[05:49] <janimo> ddaa: would the NDA at least cover other potential code or just cscvs? and how much  paperwork is it?
[05:50] <ddaa> Dunno really, you could task with sivang who I think has signed for access to launchpad code.
[05:50] <janimo> what I am afraid is that more time than what I'd spend on the code itslef.
[05:50] <janimo> right I remember him saying in parsi that he has an nda
[05:50] <jamesh> looks like kiko got revision 4000
[05:50] <janimo> s/parsi/paris/
[05:50] <janimo> sivang: ping
[05:50] <malcc> jamesh: Is there a prize?
[05:51] <ddaa> janimo: well, in any case, I'll tell SteveA about this discussion
[05:51] <janimo> ddaa: ok, thanks.
[05:52] <janimo> it'd be nicer if it could be done w/o NDA since opening the code is blocked on cleanups AIUI, but it's your call obviously
[05:53] <janimo> a kind of 'early access program' for selected people with narrow and hairy foreheads
[05:56] <ddaa> Since boring considerations like licensing terms have not been decided on yet, it's not really possible.
[05:56] <janimo> understood
[05:57] <dsnopek> ddaa:  I have to run to a meeting, but thanks for getting the import going!
[06:18] <jamesh> flacoste: ping?
[06:19] <flacoste> jamesh: pong
[06:19] <jamesh> flacoste: just been looking over your diff.
[06:20] <flacoste> jamesh: do you see any problems with it?
[06:20] <jamesh> is there any reason you copy/pasted the docstring for LaunchpadView.render() for LaunchpadFormView?
[06:20] <jamesh> there isn't any glaring problems
[06:22] <jamesh> flacoste: there is still the issue of doing one view vs. two views, but I think it is probably better at this point to merge what you've got and then look at that afterwards
[06:22] <flacoste> jamesh: no particular reason for the copy/pase, maybe I should only have left the comments related to that particular implementation
[06:22] <jamesh> flacoste: probably easier to leave it out or use "See LaunchpadView.render()"
[06:24] <flacoste> jamesh: ok, I'll remove it and leave a pointer to LaunchpadView.render(), the reason i copied it was that it provided information that one might miss if one only looks at the LaunchpadFormView.render() comment
[06:24] <flacoste> jamesh: if anybody want to try to implement it in two views, i wish them good luck in making it simpler than it is now :-)
[06:25] <jamesh> flacoste: okay.  We've been using comments of the form "See class" or "See class.method()" for implementations of interfaces.  Perhaps that'd be appropriate here
[06:26] <flacoste> jamesh: i was about to leave for lunch with bradb, is there anything else you want me to reply to before I move out (and probably you too)
[06:27] <jamesh> flacoste: nope.  You may as well merge it when you get back from lunch
[06:27] <flacoste> jamesh: great, thanks a lot!
[06:32] <jamesh> kiko-fud: you seem to have reverted a whole bunch of changes with your latest merge to rocketfuel.
[06:33] <jamesh> kiko-fud: just look at the changes between r3999 and r4000 in launchpad
[06:33] <Mez> ddaa, any update on the katapult svn branch
[06:35] <ddaa> Mez: none since we last talked about. I think we have enough information to start working on it, and filed bug 58029.
[06:35] <ddaa> https://launchpad.net/bugs/58029
[06:36] <Mez> hmm launchpad timing out for me
[06:36] <ddaa> It's not clear when we'll have resources to put on fixing it though.
[06:37] <ddaa> Yeah, launchpad seems very unhappy at the moment.
[06:37] <ddaa> Mez: since I have put an entry about that import on https://help.launchpad.net/VcsImportRequests, I'll tell you when it succeeds.
[06:37] <Mez> ;)
[06:39] <kiko-fud> jamesh, really? hmmm.
[06:40] <jamesh> kiko-fud: it's added back the <fieldset> around the bug description, moved the bug branch list back down to where it was before mpt's recent change and a bunch of other stuff
[06:40] <kiko-fud> jamesh, yeah, that was intentional.
[06:40] <Mez> hmm
[06:40] <jamesh> really??
[06:40] <Mez> I got a OOPS-243D580 on logging in
[06:40] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/243D580
[06:40] <kiko-fud> jamesh, well.. yeah. I wrote to the list about it
[06:41] <kiko-fud> jamesh, if you're only talking about reverting of the bug page formatting, and related tests, then yes
[06:41] <jamesh> where?
[06:42] <kiko-fud> jamesh, do you think that wasn't such a good idea? 
[06:42] <kiko-fud> my latest reply to mpt 
[06:42] <jamesh> kiko-fud: it resets the look to what we had about a month or so ago.  I didn't see a message about that
[06:43] <kiko-fud> jamesh, I wrote a few times to mpt about this. there's also the problem that the UI I had modified required a link to the first comment (see bug 1 for instance)
[06:43] <jamesh> it looked a lot more like messy/incorrect conflict resolution
[06:43] <Ubugtu> Malone bug 1 in ubuntu-meta "Microsoft has a majority market share" [Critical,Confirmed]  http://launchpad.net/bugs/1
[06:43] <kiko-fud> jamesh, the commit message says I was reverting the page, didn't it?
[06:44] <kiko-fud> I see it doesn't make it that explicit
[06:45] <kiko-fud> jamesh, anyway, more to the point, I am fine with changing it again /as long as/ we openly discuss it, instead of landing changes in RF
[06:45] <kiko-fud> so I'm happy with mpt doing a redesign of that part of the page, as long as he does it by discussing what he wants to improve, and not simply changing it without regard for some consensus
[06:45] <jamesh> kiko-fud: you reverted changes that were made earlier today (changes that had gone through review).  
[06:46] <kiko-fud> hmmm.
[06:48] <kiko> jamesh, I didn't approve of the UI change myself, and having been the author of the original UI, I reverted it back to what it was. at that point I invite criticism or even redesigns as long as it's openly discussed
[06:49] <kiko> jamesh, (I'm talking about the design that was there "a month or so" ago)
[06:51] <kiko> Mez, how weird. I didn't think +addsubscriber needed to do so much work.
[06:51] <kiko> Mez, did reloading fix the problem?
[06:52] <Mez> kiko: yeah ;)
[06:52] <kiko> that's kind of a bug
[06:52] <kiko> it took 100s to run a trivial query though
[06:52] <Mez> lol
[06:52] <Mez> kiko: LP seems very unhappy atm
[06:53] <kiko> again? 
[06:53] <jamesh> kiko: okay.  Ignore the description presentation bit.  mpt's landing today moved the bug branch table above the description, which you've reverted.  Could you at least undo that part?
[06:58] <Nafallo> if someone wants a bzr-bugreport they should approve my mail to bazaar-ng@l.u.c :-)
[06:59] <Mez> Nafallo, or try #bzr ;)
[07:00] <Nafallo> Mez: I think the admin of that lists would be lurking here ;-). don't know who whoever :-).
[07:00] <Nafallo> s/whoever/however/
[07:01] <Mez> Nafallo, it be mbp, who isnt in here
[07:01] <Nafallo> baah
[07:01] <Nafallo> sent there aswell then...
[07:07] <sivang> hmm, janimo looked for me..
[07:09] <sivang> ddaa: I see something about him an you on the backlog, he has some issues importing some xfce packages?
[07:09] <ddaa> yep
[07:15] <Ubugtu> New bug: #58369 in launchpad "ContextWidget should return the actual context object, not its id." [Untriaged,Confirmed]  http://launchpad.net/bugs/58369
[07:15] <Ubugtu> New bug: #58370 in launchpad "ContextWidget should return the actual context object, not its id." [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58370
[07:56] <kiko> jamesh, are we sure that's a good thing to do?
[07:56] <kiko> jamesh, I didn't see an email thread or proposal on this change.
[07:56] <kiko> jamesh, why should we do it without bringing up "a problem"?
[07:56] <kiko> BjornT, did you click twice on the submit button, or something else?
[07:59] <BjornT> kiko: i filed the bug while lp was unresponsive, so i aborted and resubmitted the request.
[07:59] <kiko> BjornT, ah. is this situation still happening?
[08:00] <kiko> BjornT, bradb: are you are of/in favor of the change that mpt and jamesh discussed on -reviews, which places the branch listing above the description?
[08:00] <kiko> s/you are/you aware/
[08:00] <bradb> -0
[08:01] <BjornT> kiko: it seems fine now. this was around the time when mez reported it was slow.
[08:01] <kiko> I'm -1 on it ftr
[08:01] <kiko> but I am confused as to why I had never heard of this before the patch was landed
[08:05] <BjornT> kiko: as for the branch listing, i think it makes sense to have the branch listing near the bugtask statuses. the branches play an important role for the status of the bug.
[08:06] <kiko> I'm not so sure that's a good argument for moving the listing up
[08:06] <bradb_> URGH. i keep getting dropped from IRC.
 One problem is that it's like asking what colour broom the office should have. I'm not yet convinced that bug branch information is at all useful on the bug page to begin with. I'd be curious to know how many bug branches we have though. kiko, can you find that out on staging?
[08:06] <kiko> for one, it will move the description down, possibly off-screen if you have a few tasks and branches
 (or prod, if possible, of course)
[08:06] <kiko> sure.
[08:07] <kiko> SteveA, ping?
[08:09] <BjornT> kiko: maybe the description should be right after the title, before the 'affects' rows?
[08:10] <kiko> BjornT, I think that may be a good idea, but the affects rows being prominent were one of the striking things in malone's design.. 
[08:10] <dsnopek> ddaa, Any word on why my import failed, or should I just watch the newly discovered (by me, that is) https://help.launchpad.net/VcsImportRequests page?
[08:10] <kiko> bradb_, I have no idea what your broom analogy means, but we have 55 bugbranches.
[08:10] <BjornT> i agree with bradb_, though, it's not a big problem atm, since we don't have many bug branches. when it gets easier (and possible for us) to register bug branches, that number will increase, though.
[08:12] <kiko> BjornT, jamesh, bradb__: this is why I'm scratching my head asking why are we spending time on something which isn't remotely a problem today?
[08:12] <bradb__> kiko: broom analogy == i see it as an issue that nobody cares about yet. further, because nobody cares about it (double-digit BugBranches!), it's hard to even learn from any changes we make the BB presentation
[08:12] <bradb__> kiko: dunno. I wouldn't have touched it.
[08:13] <SteveA> kiko: hi
[08:13] <kiko> SteveA! I missed you
[08:13] <kiko> you come to my house on the day of my daughter's wedding
[08:14] <kiko> you don't call me padrino
[08:14] <BjornT> kiko: exactly. so let's leave it for now, and revisit it when we have private branches and an easy way of registering bug branches.
[08:14] <kiko> agreed.
[08:15] <flacoste> kiko: for what it's worth, MPT implemented it to close bug 55831 and gave an explanation to jamesh on the review
[08:15] <Ubugtu> Malone bug 55831 in malone "branches shouldn't be hidden in the bug text" [Low,In progress]  http://launchpad.net/bugs/55831
[08:15] <kiko> flacoste, good data point!
[08:16] <ddaa> dsnopek: yup, I'll file it in there.
[08:16] <ddaa> dsnopek: unfortunately, it's hitting a bug in our import code
[08:19] <salgado> kiko, I answered one of your questions on PersonCreationRationale, and added a new one.  can you have another look?
[08:19] <kiko> salgado, not today. I need to review flacoste's branch and I am already uberfucked
[08:20] <flacoste> kiko: not need to review my branches, salgado and jamesh took care of that, but a review of the spec would be nice ;-)
[08:20] <kiko> I meant spec
[08:21] <kiko> you guys are terrible with me
[08:21] <kiko> I am only one 
[08:21] <flacoste> lol
[08:22] <SteveA> kiko is the one and only
[08:58] <WebMaven> SteveA: Hi
[09:04] <SteveA> hi WebMaven 
[09:04] <SteveA> matsubara: ping
[09:05] <matsubara> SteveA: pong
[09:06] <SteveA> matsubara: hi.  I wonder if stub could run a DB query to do this:  for every bug assigned to or with a subscriber of launchpad-infrastructure, unassign launchpad-infrastructure and add the infrastructure tag
[09:06] <SteveA> that might save you some effort
[09:07] <matsubara> SteveA: noted, I'll mail him asking. Do you think it would be useful do the same thing to un-milestone oops bugs and add the oops tag and the same for timeouts?
[09:09] <SteveA> yes
[09:09] <SteveA> if there are enough of them to make it a poor idea to do it manually
[09:10] <SteveA> we need to balance the effort and chance for error there against the effort of writing the DB query
[09:12] <matsubara> SteveA: 84 results for launchpad-project products {oops,timeout}milestones.
[09:15] <matsubara> SteveA: lp-infrastructure is subscribed to 69 bugs and assigned to 7.
[09:16] <SteveA> maybe we should leave lp-infrastructure subscribed... what do you think?
[09:18] <SteveA> certainly look to do queries for the oops and timeout things
[09:18] <SteveA> and I guess for the infrastructure ones too
[09:19] <matsubara> SteveA: i think it doesn't hurt. Is there any special rationale to have lp-infrastructure subscribed to those bugs?
[09:20] <SteveA> matsubara: all I can think of is so that the infrastructure team can get notified of changes
[09:20] <SteveA> but that's not such a big deal
[09:22] <matsubara> SteveA: they're already get those by being lp-developers
[09:23] <SteveA> okay, so no need for that team to remain subscribed
[09:23] <SteveA> i think if we'd had tags before, we wouldn't have used team subscriptions for this
[10:01] <somerville32> I made a bug report that is a security vulnerability two days ago and it still has not be triaged. What should I do?
[10:02] <matsubara> somerville32: bug number please
[10:03] <somerville32> Bug #58169
[10:04] <matsubara> somerville32: apparently that bug is in ubuntu
[10:04] <somerville32> Who should I talk to?
[10:04] <matsubara> somerville32: best place to ask about it is #ubuntu-bugs
[10:04] <somerville32> Ah, thanks :] 
[10:05] <matsubara> somerville32: np
[10:05] <Ubugtu> New bug: #58388 in malone "Implement a tag command in the email interface" [Wishlist,Unconfirmed]  http://launchpad.net/bugs/58388
[10:05] <kiko-afk> somerville32, it's triaged, but the importance name is confusing. ARGH.
[10:06] <kiko-afk> BjornT, bradb: any of you willing to whip up a trivial importance-renaming branch with rs=kiko?
[10:06] <kiko-afk> use the wording which was finally agreed upon, I can't recall exactly but mpt knows
[10:06] <matsubara> undecided
[10:07] <matsubara> bug 55015
[10:07] <Ubugtu> Malone bug 55015 in malone "Rename "Untriaged" to "Undecided"" [Medium,Unconfirmed]  http://launchpad.net/bugs/55015
[10:07] <bradb> kiko-afk: maybe tomorrow or something? i was in the middle of guided filebug with francis...
[10:09] <kiko-afk> bradb, that's fine, but would be nice to get it done for this next rollout
[10:09] <bradb> right, shouldn't be a problem
[10:56] <Ubugtu> New bug: #58391 in malone "People's bug lists can't be searched for tags" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58391
[11:42] <kiko-afk> bradb, have you tested on staging the changes to the upstream searches in the advanced bug search?
[11:43] <bradb> kiko-afk: nope, not yet
[11:43] <kiko-afk> bradb, you should, because you have one day to fix it again...
[11:44] <bradb> right, hrm...would tomorrow morning be ok? trying to get one more part of guided filebug done with francis before calling it a day.
[11:45] <kiko-afk> bradb, well... I'm looking at bugs that need to be forwarded upstream and already bug 43745 seems wonky...
[11:45] <Ubugtu> Malone bug 43745 in linux-source-2.6.17 "Ubuntu corrupts real time clock on some dell laptops" [Critical,Unconfirmed]  http://launchpad.net/bugs/43745
[11:46] <kiko-afk> I think it's including a rejected it shouldn't be.
[11:46] <kiko-afk> bug 43661 is also the same case I think
[11:46] <Ubugtu> Malone bug 43661 in linux-source-2.6.15 "ThinkPad X60: select() to /dev/rtc to wait for clock tick timed out" [High,Needs info]  http://launchpad.net/bugs/43661
[11:47] <kiko-afk> bradb, sure, do it tomorrow, but your list is things for tomorrow is growing :-) please write down those two bugs though since I've already researched them 
[11:47] <kiko-afk> bradb, and update me on the ML if you think they should be there (I think they shouldn't)
[11:47] <bradb> kiko-afk: right. i've noted this and the importance rename task for tomorrow morning, plus the two relevant bugs
[11:47] <kiko-afk> cool
[11:48] <kiko-afk> bradb, https://staging.launchpad.net/distros/ubuntu/+source/gnucash/+bug/55462 may also be wrong, not sure about Fix Released.
[11:48] <Ubugtu> Malone bug 55462 in gnucash "Gnucash crash" [High,Confirmed]  
[11:51] <kiko-afk> bradb, not sure about the fix released one, maybe it makes sense to stay on that list.
[11:51] <kiko-afk> bradb, hmmm. give me 2 minutes attention
[11:51] <bradb> ok...all feedback noted so far...
[11:52] <kiko-afk> https://staging.launchpad.net/distros/ubuntu/+source/gparted/+bug/48229
[11:52] <Ubugtu> Malone bug 48229 in gparted "Partition table destroyed when resizing NTFS" [Unknown,Rejected]  
[11:52] <kiko-afk> bradb, that bug is showing up when I select
[11:52] <kiko-afk>  Show only bugs that are resolved upstream
[11:52] <kiko-afk> did we agree or not to include Rejected in "resolved upstream"?
[11:53] <bradb> kiko-afk: Resolved includes rejected
[11:53] <kiko-afk> bradb, argh. was that because of that email comms with mark?
[11:53] <kiko-afk> oh possibly because of duplicates?
[11:53] <bradb> the point is that developers need to know when important changes happen upstream, and either a bug being fixed or being rejected upstream is important
[11:53] <kiko-afk> bradb, then s/resolved/closed/ perhaps?
[11:54] <kiko-afk> bradb, anyway, good point
[11:55] <kiko-afk> dude
[11:55] <bradb> kiko-afk: closed/resolved/etc. i think other bugtrackers use those terms interchangeably also
[11:55] <kiko-afk> that feature ROCKS
[11:55] <bradb> it does!
[11:55] <kiko-afk> it's amazing!
[11:57] <kiko-afk> bradb, okay those seem to be the only issues I pointed out. it would help if you could look into them and then summarize in an ML post, so I can gut it and use it as part of my report for this month's changes.
[11:57] <bradb> kiko-afk: noted
[12:00] <kiko-afk> bradb, the searches seem to working very well apart from that, so I've done the testing for you. enjoy! :)
[12:00] <bradb> kiko-afk: nice, thanks a lot for testing it and giving feedback