[12:04] <mdz> though it would be useful in some instances
[12:05] <mpt> mdz, do you use it in bugzilla?
[12:05] <mdz> occasionally
[12:05] <mdz> as a secondary sort key for severity
[12:05] <mdz> e.g., to prioritize among bugs of the same severity
[12:05] <mpt> ok, so is a bug with major severity that's P4 more important than a bug with normal severity that's P1?
[12:06] <mdz> yes
[12:06] <mpt> That makes priority by itself pretty useless for searching, I guess
[12:06] <mpt> so priority is useful only as a secondary sort after the primary sort of severity
[12:06] <mdz> I don't think I've ever searched by priority, no
[12:06] <mdz> well, that's how I use it
[12:07] <mdz> I don't know what bugzilla.mozilla.org or others do
[12:08] <mpt> So would dumping severity work if there was an increased number of priority values available?
[12:09] <mpt> e.g. 10 instead of 5
[12:11] <mpt> or would even that be unnecessary?
[12:13] <mdz> severity generally has a useful definition
[12:13] <mdz> whereas priority is just an ordered sequence
[12:13] <mdz> so it's better to have severity and not priority, than the reverse
[12:14] <mdz> severity has an implicit priority because, in general, more severe bugs are more important to fix
[12:14] <mdz> to my mind anyway
[12:14] <mpt> yes
[12:15] <mdz> I think that 10 severities is too many to choose from
[12:15] <mpt> agreed
[12:15] <mpt> I'm (a) wanting Malone to be as simple as possible (and yeah, I know it's horribly complicated elsewhere, but every bit helps)
[12:16] <mpt> and (b) wanting to avoid bunfights over what a bug's severity should be, as happens occasionally in Bugzilla, and even in Malone's bug 1
[12:17] <sabdfl> the idea was that priority is what the assignee plans
[12:17] <mdz> malone currently has severity and not priority, right?
[12:17] <sabdfl> severity is what Management Think
[12:17] <mdz> like debbugs and unlike bugzilla
[12:18] <sabdfl> mdz: Malone has both
[12:18] <mdz> sabdfl: to me, severity is inherent in the nature of the bug
[12:18] <mpt> Malone currently has both, like Bugzilla
[12:18] <mpt> and unlike debbugs and plone collector and jira and fogbuz
[12:18] <sabdfl> mdz: fair enough, but the same bug affects different users differently
[12:18] <mdz> sabdfl: while priority is subjective and may change depending on circumstances
[12:19] <sabdfl> sort order, to a certain extent, should depend on whether or not you are looking at your bugs
[12:19] <sabdfl> i want to see *my* priority bugs first
[12:19] <sabdfl> and then in severity order
[12:19] <mdz> I see. the priority is not visible in the summary table, but is on the bug task page
[12:19] <sabdfl> so things I've said are high priority, and within that in severity order, would be my order
[12:19] <sabdfl> but i would be ok if we dropped priority altogether
[12:19] <mdz> are you suggesting that a bug should have multiple priorities?
[12:20] <mdz> me too (dropped priority)
[12:20] <sabdfl> and allowed admin and assignee to fight over one knob, so to speak
[12:20] <mdz> I like the idea of being able to bump a priority of a bug without lying about its severity
[12:20] <mdz> but in practice, I don't think it really works today in bugzilla
[12:21] <mdz> and it's not clear to me how it would work in malone
[12:21] <mpt> ok
[12:22] <mdz> if priority were to trump severity, then I'd say that severity would no longer be useful
[12:22] <mdz> it would become informational, and informationally it isn't very interesting
[12:22] <mdz> rather than a sortish thing
[12:24] <mpt> would renaming severity to "Importance" mean you weren't lying if you raised it?
[12:24] <mpt> Plone Collector calls it Importance
[12:26] <sabdfl> mpt: as long as the reporter cannot arbitrarily change this, i don't mind
[12:26] <sabdfl> one knob is better, unless we can really justify the second
[12:26] <mpt> right, neither severity nor priority are on the bug reporting form currently anyway
[12:27] <sabdfl> i would be happy to hide priority for now, and resurrect it when we have a strong idea of what would change with it
[12:27] <mpt> ok, great
[12:27] <mpt> thanks for your time mdz
[12:27] <sabdfl> mpt: they should be able to change it after reporting it, unless they assign it to themselves
[12:28] <mpt> yes, we can leave it wiki-mode just as we do with the rest of the bug fields
[12:28] <mpt> and restrict that later only if it's really necessary
[12:29] <sabdfl> mpt, you are welcome to my time too. and your salary.
[12:29] <mpt> heh
[12:30] <mpt> thanks
[12:33] <mdz> mpt: and indeed they shouldn't be on the bug reporting form, except perhaps for users with established clue
[12:33] <mdz> users in general have funny ideas about severity/priority/importance of their own bugs
[12:33] <mdz> in fact I don't like the idea of them being able to change them later, either
[12:34] <mpt> yes, cognitive biases
[12:35] <mpt> (a) getting emotional about losing data/time, (b) over-estimating the bug's prevalence because of their personal experience, and (c) the CC list for the bug becomes a mini-mailing-list of people reinforcing each other's senses of the bug's importance
[12:37] <jblack> lifeless: ping
[12:37] <lifeless> pong
[12:37] <jblack> You asked me to get ahold of you?
[12:37] <lifeless> yes
[12:37] <lifeless> the  +branches/xxxxxxxx url - we tested those
[12:37] <lifeless> there should be no need for you to change *anything*
[12:37] <lifeless> why do you think there is such a need ?
[12:38] <jblack> No changes made.
[12:38] <jblack> I see two rewrite rules
[12:38] <jblack>   RewriteRule ^/(~[^/] +/[^/] +/[^/] +)/(.*) /${branch-list:$1}/$2 [L] 
[12:38] <jblack>   RewriteRule ^/\+branches/([[:xdigit:] ] {2})([[:xdigit:] ] {2})([[:xdigit:] ] {2})([[:xdigit:] ] {2})/(.*) /$1/$2/$3/$4/$5
[12:38] <lifeless> right, the second handles +branches/xxxxxxxx
[12:38] <jblack> Oh! Silly me
[12:38] <lifeless> which is for the launchpad branch scanner to use.
[12:38] <jblack> I read it wrong
[12:40] <lifeless> np. might like to add a comment inyour config there, to help ;)
[12:40] <jblack> Good idea
[02:18] <mpt> @#$%! Launchpad logging me out
[02:58] <sabdfl> mpt: it's saying "time to get outside and get some fresh air" ;-)
[03:05] <mpt> I just came back from lunch, I don't need another break that quickly :-)
[03:14] <sabdfl> mpt: ah, are you home? summer in nz must be awesome. looking forward to lca.
[03:45] <ti83smaster> yo
[03:45] <ti83smaster> whats up
[08:18] <dilys> Merge to devel/launchpad: [trivial]  add custom rules for mapping the package name "linux" in bugzilla import (r2952: James Henstridge)
[09:16] <fabbione> guys is it known that the editing of team members is all broken?
[09:16] <fabbione> (urls are messed up)
[09:19] <SteveA> what's up fabbione ?  can you show me an example?
[09:19] <fabbione> SteveA: sure..
[09:19] <fabbione> https://launchpad.net/people/ubuntu-server/+members/
[09:19] <fabbione> start from there
[09:19] <SteveA> ok
[09:19] <fabbione> click edit on one of the user awaiting approval
[09:19] <fabbione> that page is still ok
[09:20] <SteveA> k
[09:20] <fabbione> approve or decline will push you to a 404
[09:20] <fabbione> https://launchpad.net/people/ubuntu-server/+member/sivan/+members
[09:21] <fabbione> note that it should have removed +memeber/sivan and add +memebers/ to get back to the correct page
[09:21] <fabbione> The reference for this error is OOPS-B195. Please include it in any related bug report or
[09:21] <SteveA> for sivan, should i approve or decline?
[09:21] <fabbione> i just approved 
[09:21] <SteveA> maybe i'll try on staging...
[09:21] <fabbione> we can do the next one
[09:21] <fabbione> no problem
[09:21] <fabbione> just a sec..
[09:22] <fabbione> TomShwaller
[09:22] <SteveA> it's okay.  i'm doing it on staging.
[09:22] <fabbione> decline with this reason:
[09:22] <fabbione> Before applying to Ubuntu-Server team membership,
[09:22] <fabbione> please create a wiki page where you describe
[09:22] <fabbione> what are your interestes in the project and how
[09:22] <fabbione> you plan to contribute. Thanks.
[09:25] <SteveA> fabbione: i can reproduce this on the staging server now.  i can't fix it right away, but i'll file a bug report for salgado to look at when he arrives.  we'll have it fixed for the rollout on tuesday
[09:25] <SteveA> thanks for telling me about the bug
[09:25] <fabbione> ok
[09:25] <fabbione> no problem
[09:27] <carlos> morning
[09:29] <BjornT> SteveA: isn't salgado on leave still?
[09:30] <SteveA> BjornT: you're right, he is, in bolivia.  I'll look to see when he comes back.
[09:30] <SteveA> https://launchpad.net/products/launchpad/+bug/6453
[09:30] <Ubugtu> Malone bug 6453: "admin team membership redirect error" Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Guilherme Salgado, Status: Accepted http://launchpad.net/bugs/6453
[09:55] <sivang> morning all
[10:04] <jamesh> BjornT: did you accidentally put an LP checkout at /home/warthogs/archives/rocketfuel-built/launchpad/TicketTrackerEmailInterface ?
[10:04] <jamesh> or maybe someone else moved it there?
[10:05] <BjornT> jamesh: hmm, it was probably me, then. i'll check what went wrong. thanks.
[10:06] <jamesh> the files are owned by you, which means you created them, but anyone could have moved the directory there due to the permissions
[10:12] <BjornT> yeah, it seems that my brain wasn't functioning when i updated my scripts for creating new branches...
[10:17] <SteveA> hmm
[10:17] <SteveA> there is no reason why people should be able to write to rocketfuel-built
[10:17] <SteveA> lifeless: can you tighten up those permissions please?
[10:18] <jamesh> SteveA: probably because the parent directory was setgid
[10:18] <jamesh> so rocketfuel-built inherited the group ownership
[10:18] <lifeless> SteveA: ?
[10:19] <jamesh> lifeless: anyone on the warthogs team can write to the LP tree in /home/warthogs/archives/rocketfuel-built
[10:20] <lifeless> probably needs elmo to chgrp it then
[10:20] <lifeless> to the pqm group. only root can do that
[10:20] <jamesh> the pqm user should be able to
[10:20] <lifeless> no
[10:21] <lifeless> unix chgrping is a restricted operation
[10:21] <lifeless> chmod isn't, chgrp is
[10:22] <jamesh> if the pqm user is in the warthogs and pqm groups then it should be able to change the ownership
[10:23] <lifeless> jamesh: not on linux.
[10:23] <lifeless> jamesh: I've just tested in case I was confused, and it failed. 
[10:23] <jamesh> I seem to be able to do so on my box
[10:24] <jamesh> change the group of files I own between groups I am a member of
[10:24] <lifeless> anyway, I can trim the permissions, but that will allow new files to be confused. the right thing is a chgroup. 
[10:32] <lifeless> SteveA: meeting agenda says next meeting is dec 22nd?
[10:34] <SteveA> the agenda is old
[10:37] <jamesh> hi mpt
[10:38] <mpt> hi jamesh 
[10:39] <jamesh> mpt: yesterday SteveA was suggesting striking out automatic bug links for closed bugs, similar to what Bugzilla does
[10:40] <jamesh> mpt: however, in Launchpad it is possible to have a bug that has both open and closed bug tasks
[10:40] <jamesh> mpt: do you have any opinion on how to handle that case?
[10:42] <mpt> ooo
[10:42] <sivang> jamesh: maybe it beneficial to monitor a bug after it's been closed, in case it's re-discovered upstream? (if I understood right, automatic bug links will get wiped once the bug is closed?)
[10:42] <mpt> crossing them out had occurred to me, but the tasks problem hadn't
[10:43] <mpt> sivang, why would bug links get wiped?
[10:43] <jamesh> sivang: what we are talking about is the way "bug NNNN" text in bug comments gets turned into a hyperlink to the associated bug
[10:43] <mpt> oh!
[10:43] <sivang> eh, my bad - sorry.
[10:44] <jamesh> sivang: as an additional visual cue, bugzilla strikes out the "bug NNNN" text if the linked bug has been closed
[10:44] <sivang> mpt: lol :)
[10:44] <mpt> How's hacking, sivang?
[10:44] <mpt> Getting your head around the codebase?
[10:45] <sivang> mpt: Well, actually, more of waiting for rocketfuel-get to be ready, after I've worked some bits on the RFS wiki page, and daf, jblack and SteveA commented. It appears to be coming nicely, but no yet real hacking on the codebase , I'm afraid.
[10:45] <jamesh> mpt: one of the suggestions was to only strike out the text if all tasks are closed.  The alternative is to try and decide which task the user cares about
[10:45] <sivang> once it's ready, I wish to use to get a checkout.
[10:46] <daf> I think striking out if all tasks are closed is a good compromise
[10:46] <jamesh> mpt: and the "check if all bug tasks are closed" heuristic works quite well in the common case of a single bug task :)
[10:46] <mpt> Well, that would be a 90% solution
[10:47] <daf> trying to be magic would likely just be confusing and difficult to maintain
[10:47] <mpt> but eventually, daf, we'll have some derivatives that are really really slow about fixing bugs
[10:47] <daf> hmm, true
[10:47] <mpt> Treaclinux
[10:47] <daf> another heuristic would be "fixed in the thing it was originally reported against"
[10:47] <sivang> mpt: you finshed you're share of HUB drawings ? ;-) (joking, I know you're *very* busy)
[10:48] <daf> but you need to deal with cases like it being reassigned after being filed
[10:48] <SteveA> if we do this, we should have a very simple rule to start with
[10:48] <daf> agreed
[10:48] <SteveA> and then choose as we go on to either remove it entirely, or to make the rule better
[10:48] <mpt> sivang, it's been on my to-do list each day for the past several weeks
[10:48] <daf> how about "if it has one bug task, and that bug task is fixed, strike i tout"
[10:48] <SteveA> another way to do it.. fancier
[10:48] <mpt> ok
[10:49] <SteveA> is with a div that contains bug metadata that becomes visible when hovering over the bug link
[10:49] <jamesh> if 50% of the tasks are closed, strike out 50% of the characters in "bug NNNN"
[10:49] <mpt> so let's start with, if all are fixed, strike it out
[10:49] <daf> haha
[10:49] <sivang> jamesh: lol
[10:49] <mpt> most bugs now have only one task anyway
[10:49] <mpt> Well, I was thinking of a dotted strikethrough
[10:49] <SteveA> mpt: bjorn said that he thought striking out would mean invalid / rejected
[10:50] <SteveA> so, there is a risk that this is meaningful only to people who used bugzilla a lot before
[10:50] <mpt> SteveA, yeah, that causes me occasional confusion in Bugzilla too
[10:50] <mpt> so maybe this is something to be solved with the bug's icon
[10:50] <SteveA> yes
[10:50] <daf> good idea
[10:50] <SteveA> let us not do striking out now
[10:50] <mpt> in EntityPresentation or whatever it's called
[10:51] <daf> although I find myself getting confused with the different bug icons we have already
[10:51] <jamesh> I usually think of the strikeout similar to striking something off a todo list
[10:51] <mpt> currently we have:
[10:51] <mpt> * colors for priorities
[10:51] <daf> a variety of subtly different;y-coloured insects
[10:51] <mpt> * blue for external bug watches
[10:51] <mpt> that's all.
[10:51] <jamesh> it is useful in the bug dependency lists of tracker bugs like https://bugs.freedesktop.org/show_bug.cgi?id=5041
[10:51] <Ubugtu> Freedesktop bug 5041: "7.1 Release Tracker" Product: xorg, Component: Release, Severity: blocker, Assigned to: xorg-team@lists.x.org, Status: NEW https://bugs.freedesktop.org/show_bug.cgi?id=5041
[10:52] <mpt> yes, it makes such lists easier to scan
[10:52] <mpt> though, greying out could do a similar job
[10:52] <mpt> but then, Bugzilla uses grey for Unconfirmed
[10:53] <mpt> this needs a spec!
[10:53] <SteveA> mpt: maybe not different colours of the same icon, but the same icon *glowing* more brightly in a different colour
[10:53] <SteveA> so someone looking in b/w can see the distinction still
[10:53] <SteveA> from the glow
[10:53] <sivang> maybe instead of a strikeout we can have an exclemeation mark, that links to a list of how many of the related bug tasks are still open? and have a color ranging from red->>green indicating the 'shape' the bug is?
[10:53] <sivang> red meaning still a way to go, greener meaing getting there..
[10:53] <mpt> SteveA, the current bugs have different numbers of dots on their backs for that purpose
[10:53] <mpt> 1 dot = low
[10:53] <mpt> 2 dots = medium
[10:54] <mpt> 3 dots = high
[10:54] <daf> high what? severity?
[10:54] <jamesh> remember that this is going to be inline with the bug comment, so it shouldn't be too distracting.
[10:54] <daf> aliveness?
[10:54] <SteveA> i had not noticed at all
[10:54] <mpt> priority
[10:54] <jamesh> it should provide some important information at a glance without interrupting you as you read the comment
[10:55] <mpt> maybe major bugs should be scarier
[10:55] <daf> mothra-like
[10:55] <mpt> cockroaches vs. moths
[10:55] <mpt> bbiab
[10:59] <dayyan_hbb> hallo
[10:59] <dayyan_hbb> anyone can tell me?
[11:00] <dayyan_hbb> i ve visited and fill the form from shipit.ubuntu.com...to send me the copy of ubuntu
[11:00] <SteveA> hello dayyan_hbb 
[11:00] <dayyan_hbb> but it has been 3 month i've got nothing
[11:00] <SteveA> what country are you in?
[11:00] <dayyan_hbb> indonesia
[11:01] <dayyan_hbb> can you help me?... i'll try ubuntu in my school
[11:02] <SteveA> i can look into it.  but also, you can request some more CDs anyway.
[11:02] <SteveA> i will ask for your details in a private message
[11:02] <dayyan_hbb> yes ..
[11:03] <dayyan_hbb> or may i send u email... now?
[11:03] <SteveA> ah... i think freenode might be stopping you from seeing my message
[11:08] <dayyan_hbb> ups... i'm forget.. if it's OK, May i have about 20 - 30 CDs.. because i've promote ubuntu to my friends in other school and they are interested in installing ubuntu in their school
[11:17] <ddaa> sabdfl: "manage our personal APT branches in Launchpad"?
[11:47] <lifeless> ddaa: hct ?
[11:48] <ddaa> you mean s/APT/HCT/ ?
[11:48] <lifeless> yeah
[11:48] <lifeless> apt is binary
[11:48] <lifeless> but there will be personal apt repos driven by hct
[11:49] <ddaa> yes, but I do not think that ubuntu is THAT MUCH fork and forget that they have multiple APT branches...
[11:49] <ddaa> haaa, oooookay!
[11:49] <lifeless> is there some way to get __module__ from a function?
[11:51] <ddaa> I vaguely recall that epydoc was using inspect for that
[11:51] <ddaa> so I needed to monkey patch it so it would do what I tell it to.
[11:51] <lifeless> inspect.getmodule(foo) - right
[11:52] <ddaa> But some people say that inspect is evil
[11:52] <lifeless> meh, in the stdlib - will do for me
[11:52] <ddaa> and it's downright confused (broken) by symlinked situations
[11:52] <SteveA> if you try to get source code
[11:52] <SteveA> well, it may not be available
[11:52] <SteveA> for example, you may have only .pyc files
[11:53] <lifeless> it should not need that to do get_module() thought
[11:53] <SteveA> correct
[11:53] <lifeless> also, we dont support shipping bzr as .pyc, so that should not be much of a concern
[11:53] <ddaa> neither should it need to to tell me on which line some func was defined
[11:53] <lifeless> this is library symbol deprecation decoration
[11:54] <ddaa> btw, it seems that functions do have  __module__ attribute
[11:54] <lifeless> do they ? ah phew
[11:55] <ddaa> actually... the thing with epydoc is that I was cloberring it to control epydoc, and epydoc insisted on inspect
[11:55] <SteveA> using inspect ought to be fine
[11:55] <lifeless> what I actually want is the fully qualified python name for the thing
[11:55] <SteveA> and is clearer than getting __thing__ attrs directly
[11:55] <ddaa> so I had to make it more stupid so it would do what I wanted
[11:55] <lifeless> but that does not seem to be trivially accessible.
[12:05] <ddaa> I'd love to have the subscribe actions in the subscribers portlet
[12:06] <ddaa> I'm frustrated every time I want to subscribe a bug, here's how my brain works:
[12:06] <ddaa> 1. find the subscribers portlet
[12:06] <ddaa> 2. look for my name in the subscribers
[12:06] <ddaa> 3. not me, want to subscribe... where's the link???
[12:06] <ddaa> 4. panic
[12:07] <ddaa> 5. ha... yes that's an action, that's on the other column bummer
[12:08] <ddaa> 6. okay, that block here is action... "Link to CVE", "Mark as Duplicate"... "Subscribe"!
[12:08] <ddaa> 7. Click
[12:08] <ddaa> Steps 4, 5 and 6 and entirely uncessary
[12:10] <Seveas> you panic too easily :)
[12:10] <ddaa> No, seriously, if just one person says "me too", I'll file that as a bug.
[12:11] <daf> what's the bug -- "subscribe link is too hard to find?"
[12:13] <BjornT> once there was a subscribe link in the portlet, not sure why it was removed. i think it would be good to have a subscribe link near the subscribers list.
[12:13] <ddaa> Something like that.
[12:13] <daf> I suppose it wouldn't be bad to have a duplicate link in the portlet
[12:13] <jamesh> here's another UI issue (already filed a bug about it):
[12:13] <daf> let's ask mpt when he comes back
[12:14] <ddaa> Also, I guess, action portlet is too hard to read.
[12:14] <jamesh> 1. try to link a URL to a bug that already has URLs linked to it
[12:14] <jamesh> 2. now try to do the same to a bug that doesn't have URLs linked to it
[12:14] <ddaa> Could probably use some more vertical space.
[12:15] <ddaa> jamesh: what does "link a URL to a bug"?
[12:15] <ddaa> what does that mean?
[12:15] <jamesh> ddaa: you can associate a URL with a bug
[12:16] <jamesh> let me find an example
[12:16] <ddaa> use case!
[12:16] <ddaa> tell me a story uncle james!
[12:18] <jamesh> https://launchpad.net/bugs/1662 has a URL associated with it (see the portlet on the right)
[12:18] <Ubugtu> Malone bug 1662: "CVE numbering changes" Fix req. for: malone (upstream), Severity: Normal, Assigned to: Mark Shuttleworth, Status: Fixed http://launchpad.net/bugs/1662
[12:18] <ddaa> Soyuz took all the vertical space, that's why there's none in Launchpad.
[12:18] <jamesh> there is an "Add" link in the portlet to add extra URL references, but the whole portlet goes away if there are none.
[12:20] <ddaa> Duh... the "related web links" portlet is also on the wrong column!
[12:21] <daf> jamesh: presumably these URLs were added before the bug was born
[12:21] <BjornT> jamesh: well, i think that's because someone thought that adding URL to bugs was crack ;) even if there was a subscribe link in the portlet, i would still expect to find it in the actions portlet.
[12:22] <daf> there is an argument that you can just add URLs in a comment
[12:22] <ddaa> BjornT: Agreed, it's useless. The same effect is achieved by putting the link in the description.
[12:26] <zyga> carlos: hello
[12:26] <carlos> zyga, hi
[12:27] <zyga> carlos: I plan to do some catch up in the next few days regarding the gnome sync
[12:27] <zyga> has there been any progress with that?
[12:27] <carlos> zyga, no, sorry
[12:27] <carlos> holidays and other critical fixes...
[12:27] <zyga> exactly :-)
[12:28] <zyga> carlos: has there been any progress on implementing search in rosetta?
[12:28] <carlos> zyga, nothing outside the spec we wrote 
[12:29] <zyga> carlos: are the exports working properly/
[12:30] <matsubara> good morning!
[12:30] <carlos> zyga, they should work, yes, but there are some bugs still around
[12:31] <zyga> carlos: are you planning any export soon?
[12:31] <ddaa> BTW is there any reason, besides "it's not done yet", why the "subscribe link" does not use JS to POST the subscription form?
[12:32] <ddaa> I understand why subscription should be done by post, and why it should look like a link, but I think the extra click is just annoying.
[12:33] <ddaa> not to mention the extra page loading
[12:33] <daf> hmm
[12:33] <zyga> carlos: the package list distro/lang is corrputed :/
[12:33] <daf> ddaa: I think that is an excellent idea, and certainly worth filing a bug about
[12:33] <carlos> zyga, ?
[12:34] <zyga> carlos: https://launchpad.net/distros/ubuntu/dapper/+lang/pl
[12:34] <ddaa> daf: one caveat is that I'm not really sure that you can do that sort of thing with JS (out of sheer ignorance).
[12:34] <zyga> I can make a screenshot if you'd like
[12:34] <zyga> the right float corrupts the list
[12:35] <carlos> zyga, yeah, we are fixing those pages to fit inside the new layout
[12:35] <daf> ddaa: yes, you can
[12:35] <zyga> carlos: ok, great
[12:35] <daf> Launchpad doesn't use any stuff like this yet, but we should
[12:36] <ddaa> daf: okay, will file a bug
[12:45] <kiko-zzz> morning
[12:45] <zyga> carlos: hum, what is a translator supposed to do when the msgid contains an entity and that entity is not escaped, thus, hard to type (unless you know the entity in question)?
[12:45] <zyga> carlos: I'm looking at the &trade; sign that got displayed as small 'tm'
[12:46] <mpt> zyga, copy and paste?
[12:46] <BjornT> mpt: i'm finishing off FormLayout. can you give an example of a field which is automatically converted to lowercase?
[12:46] <zyga> mpt: not good
[12:46] <daf> jamesh: did you say you'd fixed the tests that had 2005 hardcoded into them?
[12:46] <mpt> BjornT, any of the "this will be used in an URL" fields, e.g. product name, project name, distro name
[12:46] <zyga> mpt: the msgstr should contain &trade; not the unicode character that corresponds to this character
[12:47] <zyga> s/character$/entity/
[12:47] <mpt> zyga, so the "English:" row should be showing "&trade;" but it's showing TM instead?
[12:47] <daf> that's a problem with the original package, not Rosetta, I think
[12:47] <zyga> mpt: exactly
[12:47] <mpt> that's a bug
[12:48] <daf> Rosetta escapes entities, I'm pretty sure
[12:48] <zyga> hmm
[12:48] <zyga> I'll check the source
[12:48] <mpt> iirc I ran past the bugmail from that bug today, closed due to lack of reproducability
[12:50] <lifeless> SteveA: how does pydoc generate the text for the right hand side of functions it lists:
[12:50] <lifeless> bzrlib.get_bzr_revision = decorated_function(*args, **kwargs)
[12:50] <lifeless> seems ugly, and an unintended side effect of function decoration
[12:50] <jamesh> daf: yeah.  There was only one that caused a problem.
[12:51] <ddaa> bug 6457
[12:51] <Ubugtu> Malone bug 6457: "Subscribe should work in one click" Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Nobody, Status: New http://launchpad.net/bugs/6457
[12:51] <daf> jamesh: cool
[12:51] <ddaa> also bug 6456
[12:51] <ddaa> #6456
[12:51] <ddaa> bug 6456
[12:51] <Ubugtu> Malone bug 6456: "Subscribe actions are too hard to find" Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Nobody, Status: New http://launchpad.net/bugs/6456
[12:51] <zyga> ddaa: doesn't amazon have a patent on one click stuff? :)
[12:52] <ddaa> zyga: we are not e-commerce, Amazon does not give shit about us.
[12:52] <kiko> ddaa, I think zyga was joking
[12:52] <zyga> :-)
[12:53] <zyga> mpt: it's not a bug the original template does contain 'tm' 
[12:53] <ddaa> sorry, I fail to find patents funny...
[12:53] <daf> I'm not sure US patent law would apply to us
[12:53] <BjornT> mpt: ok, it seems that no conversion is done today, though. i'll take a look at how to do it.
[12:54] <mpt> BjornT, there was one I remember, Morgan Collett implemented a back-end validator for it
[12:55] <mpt> zyga, so it's a bug in the original package?
[12:55] <kiko> heya stub
[12:56] <zyga> mpt: I think that text might come from glade, someone probably copied the 'tm' from the char palette
[12:56] <mpt> zyga, if characters like that should never appear in templates, report a bug that Rosetta should ignore strings containing them on import
[12:57] <mpt> (so that people can still translate the other strings while the developers fix the wonky characters)
[12:57] <zyga> mpt: it works okay but you need to manually copy-paste :/
[12:57] <stub> Yo
[12:57] <mpt> (and by "ignore" I mean "ignore and whine", not "silently ignore")
[12:57] <daf> yo stub
[12:57] <kiko> how's it going man
[12:58] <BjornT> mpt: ah, now i found it. nothing that can be used, though :( and actually, i think the validator will complain on the capital letters before it gets converted...
[12:58] <SteveA> lifeless: function decoration has some unintended side effects.
[12:59] <lifeless> SteveA: yes. We're planning on using it in bzrlib to document api deprecation
[12:59] <lifeless> SteveA: thats the only wart I've found so far
[12:59] <SteveA> MEETING TIME
[12:59] <daf> meeting o'clock!
[12:59] <lifeless> dude
[12:59] <SteveA> welcome to the launchpad development meeting
[12:59] <lifeless> its a meeting
[12:59] <SteveA> who's here today?
[01:00] <daf> me
[01:00] <stub> kiko: Good enough. Bit of a break :)
[01:00] <BjornT> me
[01:00] <bradb> me
[01:00] <matsubara> me
[01:00] <jamesh> me
[01:00] <kiko> me of course
[01:00] <gneuman> me
[01:00] <mpt> me
[01:00] <lifeless> you
[01:00] <jblack> me
[01:00] <SteveA> kiko: salgado still on vacation in bolivia?
[01:00] <stub> yo
[01:00] <kiko> yeah, till the end of next week SteveA 
[01:00] <SteveA> kinnison is back monday
[01:00] <lifeless> spiv is still on leave
[01:01] <SteveA> back monday, i think
[01:01] <mpool> hi all
[01:01] <kiko> hey mpool 
[01:01] <SteveA>  * Roll call
[01:01] <SteveA>  * Agenda
[01:01] <SteveA>  * Next meeting
[01:01] <SteveA>  * Activity reports
[01:01] <SteveA>  * Items from last meeting
[01:01] <SteveA>  * Production / staging (stub)
[01:01] <SteveA>  * Requiring tests for merges. (RobertCollins)
[01:01] <SteveA>  * UI coordination (SteveAlexander)
[01:02] <SteveA>  * Keep, Bag, Change
[01:02] <SteveA>  * Three sentences
[01:02] <SteveA> 
[01:02] <SteveA> this is quite a short agenda
[01:02] <SteveA> anything else needed today?
[01:02] <SteveA> okay
[01:02] <ddaa> Oh, completely forgot about that :)
[01:02] <SteveA> items from the last meeting...
[01:02] <SteveA> i didn't write it up :-(  
[01:03] <SteveA> so, let's move onwards
[01:03] <SteveA> wow, thanks daf
[01:03] <SteveA> next meeting
[01:03] <kiko> daf, I have about 3000 mails to read, wanna read them for me too? 8)
[01:04] <daf> er
[01:04] <SteveA> i'll be in london next week, at some meetings
[01:04] <kiko> I guess er means no
[01:04] <daf> I don't think I have your mail-reading superpowers
[01:04] <SteveA> i'll try to make this meeting, but i'm not sure i'll have time
[01:04] <SteveA> if not, kiko, can you run next week's meeting?
[01:04] <kiko> sure.
[01:04] <SteveA> thanks
[01:04] <SteveA> same time, 12UTC, on the 12th jan ?
[01:05] <SteveA> it is done
[01:05] <SteveA>  * activity reports
[01:05] <mpt> up to date
[01:05] <lifeless> godlike
[01:05] <mpool> uptdate
[01:05] <jblack> out of date
[01:05] <BjornT> i'm up to date
[01:05] <bradb> up to date
[01:05] <matsubara> up to date
[01:05] <stub> Up to date I think
[01:05] <daf> up to date
[01:05] <jamesh> I'm not.
[01:05] <gneuman> up to date
[01:05] <kiko> I only sent one for yesterday, so..
[01:06] <ddaa> uptoodeight
[01:07] <SteveA> ok
[01:07] <SteveA>  * Production / staging (stub)
[01:07] <sivang> (had something in the office)
[01:07] <stub> Staging is getting daily code updates. The database was synced to production over the break.
[01:07] <stub> I'm unsure if a production update is needed next week. I'll trawl the commits list tomorrow (when I'm back from leave) and make a call then, unless anyone has strong opinions and can save me the bother.
[01:07] <SteveA> stub: i want to do the bugzilla migration next week
[01:07] <SteveA> there are various things that must be rolled out for that
[01:07] <carlos> SteveA, I'm here, sorry. I was distracted
[01:08] <stub> I have breezy upgrades tentatively scheduled for next week at the moment
[01:08] <ddaa> spring already, bugs start migrating away from the tropics
[01:08] <SteveA> also, there is a bug in the team management UI that should be fixed
[01:08] <carlos> I'm a week behind
[01:08] <SteveA> stub: do you want to do the breezy upgrades before the bugzilla migration?
[01:08] <stub> Is bugzilla migration ASAP? If so, I'll reschedule the breezy upgrades
[01:09] <SteveA> i'm wary of pushing the bugzilla stuff back much more
[01:09] <SteveA> as it is already delayed much
[01:09] <SteveA> all the pieces are in place for it
[01:09] <sivang> SteveA: using malone instead of bugzilla means Soyuz also has to be operational ?
[01:09] <SteveA> sivang: no
[01:09] <carlos> stub, also, you have some patches into your review queue that must be merged into production as soon as possible
[01:09] <carlos> stub, are related with timeouts
[01:09] <stub> ok. If james is ok with the schedule, we will do bugzilla by wednesday.
[01:09] <SteveA> ah yes
[01:10] <SteveA> stub: you have emails from me about timeouts
[01:10] <SteveA> i disabled translation suggestions in production
[01:10] <sivang> SteveA: ok, some emails on the ml suggested these go together, however I probably misunderstood.
[01:10] <kiko> stub, that sounds good.
[01:10] <kiko> stub, is gina running on a cronjob yet?
[01:10] <SteveA> carlos has worked to improve the code / queries for these things
[01:10] <SteveA> so carlos' changes need to land, so that we can turn suggestions back on
[01:10] <stub> kiko: I think so... 
[01:11] <SteveA> also, jamesh's initial bug contacts script should run in production today or tomorrow
[01:11] <stub> What is the initial bug contacts script?
[01:12] <SteveA> stub: i turned off two cron jobs -- karma cache updater and stats updater
[01:12] <jamesh> stub: it is to migrate the initial contacts from bugzilla to Launchpad
[01:12] <jamesh> stub: so that the right people get email when new bugs get filed on Ubuntu
[01:12] <SteveA> if we run that now, distro people won't "lose" bugs that people eagerly file in launchpad
[01:13] <stub> kiko: Gina is running daily on -updates, -security, -backports and dapper
[01:13] <SteveA> before we have done the migration
[01:13] <kiko> stub, thanks man.
[01:13] <stub> jamesh: Does it rely on any of bradb's work that got backed out accidently?
[01:14] <jamesh> stub: only bradb's bug status changes were backed out -- the initial contacts stuff looks like it is in production
[01:14] <bradb> It is in production.
[01:14] <kiko> right
[01:14] <kiko> and the status migration will happen later
[01:15] <cprov> stub: btw, did we discover why those changes get backed out by my last commit ?
[01:15] <SteveA> cprov: not as of yesterday.  lifeless may know more
[01:16] <cprov> SteveA: ok, I'm kind of concerned ...
[01:16] <lifeless> no, its definately a bad base selection, but we dont have enough info to reproduce or identify the cause
[01:16] <stub> ok. So first issue is to update production, then run initial bug contacts scripts, then perform bugzilla bug migration
[01:16] <SteveA> stub: so, do we have a plan for production?  carlos' suggestions patch, a fix for team membership pages, run jamesh's initial contacts script, bugzilla migration next week
[01:17] <lifeless> jamesh has been looking at it
[01:17] <kiko> stub, note that when we perform the bugzilla bug migration we need to disable the ubuntu bugzilla entirely
[01:17] <SteveA> right.  we need to coordinate with admins for that
[01:17] <kiko> (to avoid people still commenting or changing bugs there)
[01:17] <stub> There are  patches in my review queue that are important. Can we leave the production update until Tuesday, giving me tomorrow and the weekend to land those patches?
[01:17] <jamesh> lifeless: I've got no clue about how it happened -- just that the backouts definitely occurred with cprov's merge.
[01:17] <SteveA> there is a document on this process
[01:17] <SteveA> and any further notes on it should go in that doc
[01:17] <stub> kiko: Not my department ;)
[01:18] <SteveA> https://wiki.launchpad.canonical.com/BugzillaImportProcess
[01:18] <lifeless> jamesh: yes, I know.
[01:18] <kiko> stub, well, I'm just pointing out that that needs to be done at the same time as the production run -- I will help coordinate
[01:18] <cprov> jamesh: but not inside that specific branch, as I've verified too.
[01:18] <jamesh> cprov: yep.  That's what I found too.
[01:19] <kiko> cprov, it happened during pqm's merge, but damned if I know how a bad base selection can revert patches applied.
[01:19] <kiko> that has to be a pretty catastrophic base
[01:19] <daf> all our base are belong to pqm
[01:19] <SteveA> the current agenda item is Production / Staging
[01:19] <SteveA> stub: anything else on that?
[01:20] <jamesh> stub: that sounds fine.  
[01:20] <ddaa> kiko: picking a base on rocketfuel that's not in the branch being merged would do that.
[01:20] <SteveA> please focus on the meeting.  i can add an agenda item for the bzr mystery.
[01:20] <kiko> ok
[01:20] <cprov> ok
[01:20] <SteveA> stub: anything else on that?
[01:20] <stub> SteveA: That should do
[01:20] <SteveA> cool
[01:20] <SteveA>  * Requiring tests for merges. (RobertCollins)
[01:21] <lifeless> SteveA: this was covered in the last meeting.
[01:21] <SteveA> ok
[01:21] <SteveA>   * UI coordination (SteveAlexander)
[01:21] <ddaa> care to remind?
[01:21] <SteveA> go ahead lifeless 
[01:21] <ddaa> (as there was no summary for last meeting)
[01:21] <SteveA> (rub it in ddaa! ;-) )
[01:21] <lifeless> the review team are now requiring 'reasonable' test coverage for branches as part of the things they check
[01:22] <ddaa> please expand on "reasonable"
[01:22] <lifeless> ddaa: if its unreasonable, you'll know.
[01:22] <SteveA> feel free to discuss the kind of tests you intend to use with a reviewer
[01:23] <lifeless> common sense essentially. The reviewers are here to ensure that code going into the trunk is of good quality; tests are part of that quality.
[01:23] <lifeless> anyone on the review team should be able to help you guys if you need assistance in testing.
[01:23] <lifeless> but the key thing is - *expect* that untested code will get hauled up during review.
[01:24] <ddaa> I'd like that test that just do "import foo" be considered unreasonable. That properly tested by just doing the import in the test module root.
[01:24] <ddaa> lifeless: you know who I am picking at :)
[01:24] <lifeless> ddaa: yes, and its not really relevant right here and now
[01:24] <SteveA> i want to move on
[01:24] <SteveA>   * UI coordination (SteveAlexander)
[01:25] <SteveA> i've been working with various people on launchpad UI, and I'm having regular conversations with mark about it
[01:25] <SteveA> the launchpad UI in general has improved a lot lately.  i've had positive comments from members of the distro team, and mark has had such comments too
[01:25] <SteveA> well done to all who work on UI in launchpad
[01:26] <mpool> hear hear
[01:26] <kiko> that must mean everybody
[01:27] <SteveA> I want to keep helping out with the UI, and making connections between mark's plans, users' needs, specs and code
[01:27] <SteveA> i need some help to do this
[01:27] <SteveA> specifically, when there are UI discussions on irc or in person, please post a summary to the mailing list
[01:27] <SteveA> or invite me to take part in the discussions
[01:27] <stub> Does this cover the 'new look', and we won't be reverting to the plone-look?
[01:27] <ddaa> what about just filing a bug?
[01:28] <sivang> SteveA: I am very interested in helping on that, as much as I can at the moment.
[01:28] <kiko> stub, I think we won't be reverting, no. do you miss it?
[01:28] <SteveA> if there are UI features and workflows specced out, have a discussion (involving me in some way please) before changing the spec
[01:28] <SteveA> sivang: that's great.  let me know if there are specific things you want to be involved in
[01:29] <stub> kiko: No - just that it was a major change and if it is going to be vetoed by anyone, the sooner the better
[01:29] <SteveA> ddaa: file a bug about UI stuff, but consider subscribing me to it
[01:29] <SteveA> matthew is still our UI and usability guru
[01:29] <kiko> stub, I think mark is pleased with where it's going.
[01:29] <sivang> SteveA: sill do, thanks.
[01:29] <sivang> kiko: it's very slick IMHO right now
[01:29] <SteveA> matthew and I will be talking on voip calls a lot over the coming months
[01:30] <sivang> a very big improvemnt
[01:30] <ddaa> It would be great if specs had more UI coverage. Mock-ups, message texts, etc.
[01:30] <SteveA> and sorting out where we're going with UI and workflow as a whole
[01:30] <sivang> maybe we should include a mandatory section in a spec , UI :-) and nag people who forget to work it
[01:30] <sivang> or help them to work it out if they need some help
[01:31] <ddaa> http://www.joelonsoftware.com/articles/fog0000000035.html
[01:31] <ddaa> and other articles in the same serie
[01:31] <SteveA> so, this agenda item is all about this: keep matthew and me involved in UI discussions.  involve us in UI discussions and decisions.
[01:31] <kiko> ddaa, we've done that before, though perhaps the UI was not done with the appropriate consideration for design principles <wink> 
[01:31] <SteveA> any other questions or points?
[01:32] <SteveA> ok
[01:32] <bradb> SteveA: one thing
[01:32] <SteveA>  * Keep, Bag, Change
[01:32] <SteveA> ...
[01:32] <SteveA> yes?
[01:32] <bradb> SteveA: Who needs to signoff on UI changes to a spec?
[01:32] <sivang> maybe we could use the users list / distro team to give feedback on UI changes as well
[01:32] <sivang> (before there is a change done)
[01:32] <SteveA> bradb: me or matthew
[01:33] <bradb> ok
[01:33] <daf> bag: timeouts
[01:33] <SteveA> kiko can too
[01:33] <bradb> ok
[01:33] <SteveA>  * Keep, Bag, Change
[01:33] <daf> bag: timeouts
[01:33] <kiko> daf, that may be misunderstood :)
[01:33] <daf> good point :)
[01:34] <jblack> Keep: Send email followups
[01:34] <kiko> change: making it clear that error reports and timeouts are only unique within a single day.
[01:34] <daf> kiko++
[01:34] <SteveA> i'm going to do a 5s countdown on keep, bag, change, and then we can discuss 
[01:34] <SteveA> 5
[01:34] <jamesh> daf: you'd prefer the requests to continue forever?
[01:34] <ddaa> Bag: insane rosetta error spam
[01:34] <SteveA> 4
[01:34] <SteveA> 3
[01:34] <bradb> change: make error reports web accessible
[01:34] <SteveA> 2
[01:34] <kiko> jamesh, that's the misunderstanding I meant
[01:34] <kiko> bradb, that's in the queue
[01:34] <SteveA> 1
[01:34] <bradb> ok
[01:34] <ddaa> Change: SM error reporting, somehow
[01:34] <SteveA> okay
[01:34] <SteveA> in order...
[01:34] <daf> jamesh: no, that we should make an effort to make all pages load within the timeout period
[01:34] <SteveA> daf: kiko wants to talk timeouts in a second
[01:35] <daf> ok
[01:35] <kiko> I need stub's help 
[01:35] <jamesh> kiko: after the next rollout, OOPS IDs will be unique within a given 1 month period.
[01:35] <SteveA> jblack: what do you mean "email followups"? 
[01:35] <ddaa> Change: more launchpad-errors topics!!
[01:35] <daf> jamesh: cool!
[01:35] <kiko> thanks jamesh -- and hopefully a web-generated reference will be eternally unique
[01:35] <jblack> Irc conversations, pings without response. Keep sending emails about that sort of things so details aren't lost in scrollback
[01:35] <stub> ddaa: Indeed. They all got nuked for no known reason and have not been recreated.
[01:35] <SteveA> okay.  so i reiterate kiko's call last month
[01:35] <SteveA> SEND EMAIL!
[01:36] <SteveA> kiko change: making it clear that error reports and timeouts are only unique within a single day.
[01:36] <SteveA> kiko: we're adding a day-of-month to OOPS reports
[01:36] <lifeless> ddaa: SM error reporting ?
[01:36] <jblack> already resolved.
[01:36] <jblack> already agreed, that is
[01:36] <kiko> and a web-reference would be globally unique? (i.e. include the date in the URL path?)
[01:36] <ddaa> lifeless: talked about that with jblack yesterday, plan to write an email with my wishes
[01:36] <SteveA> yes, the web reference is the path reference
[01:36] <lifeless> I thought it was a standard TODO rather than something done but wrong.
[01:37] <lifeless> ddaa: please do.
[01:37] <SteveA> it is totally unique
[01:37] <kiko> I just want to make sure that we can find the damned oops months after the bug is filed.
[01:37] <jamesh> kiko: I'm going to put together a CGI script for accessing the error reports on chinstrap
[01:37] <kiko> okay
[01:37] <kiko> thanks 
[01:37] <ddaa> lifeless: I would just like some sort of really CRUDE error reporting on the launchpad-errors mailing list, just to have SOMETHING.
[01:37] <jamesh> kiko: which would give a permanent URL
[01:37] <daf> jamesh: heh, I was about to do that :)
[01:37] <SteveA> okay, hold up
[01:37] <SteveA> let's get organized
[01:37] <SteveA> any Keep, Bag, Change points still outstanding?
[01:37] <SteveA> i mean, ones already raised
[01:37] <SteveA> that we don't understand yet
[01:37] <mpt_> sorry, got disconnected
[01:38] <stub> I've added ddaa's request to my todo list
[01:38] <SteveA> ok, cool
[01:38] <SteveA>  kiko: timeouts
[01:38] <kiko> thanks
[01:38] <kiko> 99.4% of our users have reported in an internal poll that timeouts are currently the most critical issue affecting launchpad
[01:39] <kiko> and the sab himself pronounced himself on the issue yesterday
[01:39] <ddaa> stub: BTW a "anything else" topic that matches nothing would be useful.
[01:39] <sivang> kiko: sab ?
[01:39] <kiko> saying that the current situation is unacceptable, and that we need to find a way to improve this in the very short term.
[01:39] <stub> ddaa: There is a specific option for saying 'give me messages that match no topic'
[01:39] <sivang> eh
[01:39] <daf> sivang: Mark
[01:39] <sivang> right :)
[01:40] <ddaa> stub: yes, but that only works if at least one topic is selected...
[01:40] <kiko> stub, are there any things we could do that would give us a general improvement?
[01:40] <kiko> mark has suggested postgresql 8.1.1, for instance
[01:40] <SteveA> ddaa: stay on topic
[01:40] <kiko> improving the hardware on emperor
[01:40] <stub> kiko: Some steps have already been taken - disabling karma and various cache generation code. We get more timeouts when they are running
[01:40] <kiko> database replication/mirroring
[01:41] <stub> PostgreSQL 8.0 will be an improvement
[01:41] <stub> PostgreSQL 8.1 would also be an improvement, but we arn't ready to do that yet.
[01:41] <daf> we could run karma/translation stats code on a replicated DB
[01:41] <daf> less contention
[01:41] <kiko> stub, yeah, but we're still getting timeouts, and from the look of it, it's happening all over
[01:41] <kiko> we're going to move the distro team onto malone next week
[01:42] <kiko> what happens when nobody can access malone because everything times out?
[01:42] <SteveA> kiko, stub: we need to discuss this after the meeting
[01:42] <stub> kiko: There may be some rogue queries - there is an email from elmo re: load on emperor
[01:42] <daf> what's blocking a postgres upgrade?
[01:42] <SteveA> because there is no clear resolution to the discussion right now, and we need to do 3 sentences
[01:42] <kiko> okay -- final call on the topic: please concentrate on fixing any outstanding, critical performance bugs, in the next 2 weeks.
[01:42] <SteveA> we will continue "timeouts" immediately after the meeting
[01:42] <kiko> sure.
[01:42] <SteveA> * Three sentences
[01:42] <stub> daf: bugzilla rollout now, as that bumped the breezy upgrade until later (PostgreSQL 8 will be done as part of the breezy upgrade)
[01:42] <daf> ah
[01:43] <ddaa> DONE: vacation
[01:43] <ddaa> TODO: catch up, deploy bzrsyncd, OptionalBranchTitle
[01:43] <ddaa> BLOCKED: no
[01:43] <sivang> TODO: 1)Help matsubara reproduce OOPS issue when registering a couple of specs in a row. 2) test rocketfuel-get when it's done.
[01:43] <sivang> 3) if (2) successful, find some  launchpad dev and bribe him to show show me around the mountain.
[01:43] <BjornT> DONE: reduced the number of statuses in the support tracker. fixing bugs. finished implementing TicketTrackerEmailInterface. added most of the implementation section to FormLayout. started on SupportTrackerViews implementation.
[01:43] <sivang> DONE: Tried to get some rocketfuel, found some glitches in the howto wiki page, made some comments (worked with daf and jblack on that). helped some users question on the IRC channel.
[01:43] <matsubara> DONE: holiday break, implemented canned search for bugs someone commented on, some bug triage
[01:43] <BjornT> TODO: vacation
[01:43] <matsubara> TODO: finish the above, more bug fixing 
[01:43] <matsubara> BLOCKED: nope
[01:43] <BjornT> BLOCKED: no
[01:43] <sivang> BLOCKED: still , lack of time.
[01:43] <jamesh> DONE: more preparation for bugzilla import / error reporting stuff / other bug fixing
[01:43] <daf> DONE: bug triage, work on Soyuz UI, bug fixage
[01:43] <daf> TODO: more bug triage, land fixes, summarise meeting
[01:43] <daf> BLOCKED: no
[01:43] <jamesh> TODO: bugzilla migration / error reporting stuff / code reviews
[01:43] <jamesh> BLOCKED: no
[01:43] <jblack> DONE: supermirror devel, bzr-help submission, bzr support
[01:43] <jblack> DONE: rocketfuel docs
[01:43] <carlos> DONE: #5751 and #6410
[01:43] <lifeless> DONE: bzr deprecation support, many reviews, bzr update for lp
[01:43] <lifeless> TODO: too much to list
[01:43] <lifeless> BLOCKED: Zope3 update, SteveA week 7
[01:43] <SteveA> DONE: vacation, management, code review
[01:43] <SteveA> TODO: code review, zope3 update, meetings in London
[01:43] <SteveA> BLOCKED: no
[01:43] <gneuman> DONE: catch up 
[01:43] <kiko> DONE: Get back on top of email, continue evaluating Soyuz deployment testing, general management
[01:43] <kiko> TODO: Soyuz deployment, concentrating on getting timeouts nailed, perhaps fixing a bug or two
[01:43] <kiko> BLOCKED: not ultimately blocked on anything, but it could stop raining
[01:43] <jblack> TODO: Rocketfuel doc testing, bzr support, bzr doc fixes
[01:43] <carlos> TODO: Fix poimport script, finish POMsgSetPage
[01:43] <jblack> BLOCKED: none
[01:43] <carlos> BLOCKED: no
[01:43] <gneuman> Blocked: need revisor
[01:44] <bradb> DONE: Mostly finished BugStatusChangesAsComments.
[01:44] <bradb> TODO: Submit BugStatusChangesAsComments for review. Fix performance bugs while waiting for review. Bugzilla migration firefighting, hopefully.
[01:44] <bradb> BLOCKED: No.
[01:44] <gneuman> TODO: few nore content fields
[01:44] <cprov> DONE: merged old buildd/soyuz ui + dogfood soyuz deployment test
[01:44] <cprov> TODO: continue soyuz rollout (sorting scoring build)
[01:44] <cprov> BLOCKED: none
[01:44] <daf> stub: presumably breezy has 8.0 rather than 8.1, which would keep us from upgrading to that
[01:44] <stub> DONE: developer exceptions, leave
[01:44] <stub> TODO: bugzilla migration, timeout issues, production breezy upgrade
[01:44] <stub> BLOCKED: time
[01:44] <SteveA> daf: stay on topic please
[01:44] <jblack> stevea: Note, I gave two done lines
[01:45] <SteveA> noted
[01:45] <stub> daf: Yes, although we can get 8.1 into backports I suspect. More that it is very new.
[01:45] <SteveA> i don't see any blockers except gneuman's "need revisor"
[01:45] <SteveA> gneuman: please write BLOCKED in future, for ease of grepping later
[01:45] <lifeless> SteveA: and mine
[01:45] <SteveA> oh yea
[01:45] <gneuman> sorry
[01:46] <SteveA> we just talked about that in privmsg
[01:46] <lifeless> SteveA: bit of a blind spot ? :)
[01:46] <SteveA> too much testing can have that effect, i hear
[01:46] <mpool> DONE: vacation catchng up, plan travel
[01:46] <SteveA> okay, it's a wrap... and we've overrun by 2 mins.  sorry about that.
[01:46] <mpool> TODO: more design replies, 0.7rc1 release
[01:46] <mpool> BLOCKED: no
[01:46] <SteveA> MEETING ENDS
[01:47] <sivang> mpool: just in time :)
[01:47] <kiko> good ole SteveA, as reliable as a clock
[01:47] <jblack> gone
[01:47] <SteveA> continuing the timeouts discussion...
[01:47] <lifeless> SteveA: setting __name__ helps pydoc
[01:47] <SteveA> jamesh will be implementing "soft timeouts"
[01:47] <SteveA> where we'll get a warning in the OOPS logs
[01:47] <mpt> @#$%
[01:47] <SteveA> of when requests are approaching timeout
[01:48] <carlos> ok
[01:48] <ddaa> stub: so, as I said, you can only use the "send message matching no topic" if you have at least one topic selected.
[01:48] <ddaa> stub: therefore a "Nothing" topic is useful to get "Anything else" behaviour.
[01:48] <stub> ddaa: I caught that. I'll add it.
[01:48] <kiko> stub, SteveA: when can we reconvene and talk performance?
[01:49] <SteveA> we can go to #c-m where it is quieter
[01:49] <kiko> or #launchpad-performance
[01:54] <mpt> carlos, should all those ".../+translate gave me a timeout" bug reports be duplicates of bug 5751?
[01:55] <mpt> Ubugtu, wake up
[01:55] <mpt> malone 5751
[01:55] <carlos> mpt, usually, yes
[01:55] <Ubugtu> Error: I cannot access this bug.
[01:55] <carlos> mpt, if you can see the backtrace and be sure that it's related with suggestions....
[01:55] <mpt> carlos, oh, 5751 is private
[01:55] <carlos> that would be better
[01:55] <carlos> mpt, yep
[01:56] <mpt> I haven't figured out what directory backtraces are in yet
[01:57] <kiko> in /srv/gangotri-logs
[01:57] <kiko> as discussed in email
[01:59] <mpt> https://wiki.launchpad.canonical.com/?action=fullsearch&context=180&value=gangotri&fullsearch=Text
[01:59] <mpt> no wonder I couldn't find it
[02:00] <mpt> thanks kiko, I'll put that on the wiki where it should be :-)
[02:00] <kiko> sure.
[02:02] <bradb> stub: ping
[02:02] <carlos> dudes, I'm leaving now, will read the email tonight just in case there is something that needs my attention. I will be online next Saturday and Sunday. Cheers.
[02:03] <kiko> carlos, okay.
[02:03] <carlos> stub, I will try to merge my branches into rocketfuel as soon as I get an answer from your review.
[02:04] <stub> bradb: in meeting
[02:04] <bradb> stub: ok, when's a good time to discuss targetname cache search with you?
[02:08] <jamesh> mpt: in scrollback, I saw you said you were having trouble with the new javascript for collapsible fieldsets (e.g. the "Add comment to this bug" link)
[02:08] <jamesh> mpt: do you have any other details?
[02:11] <mpt> jamesh, I reported a bug on it
[02:12] <mpt> jamesh, https://launchpad.net/products/malone/+bug/6434
[02:12] <Ubugtu> Malone bug 6434: "Clicking "Add comment to this bug" reloads the page then jumps to the top" Fix req. for: malone (upstream), Severity: Normal, Assigned to: Nobody, Status: New http://launchpad.net/bugs/6434
[02:13] <jamesh> mpt: this is with Safari?
[02:13] <mpt> yes
[02:13] <jamesh> mpt: sounds like the click event isn't being cancelled correctly
[02:14] <mpt> imo that control should be a checkbox
[02:16] <mpt> but it hadn't occurred to me that it would be browser-specific
[02:16] <mpt> anyway, it's 2.16am and I'm dangeously grouchy, so I'm going to sleep
[02:16] <kiko> mpt, talk to me tonight.
[02:17] <mpt> kiko, as in how many hours from now?
[02:17] <kiko> mpt, when you wake up
[02:18] <mpt> ok
[02:18] <mpt> jamesh, http://www.irt.org/script/55.htm might be useful
[02:20] <jamesh> mpt: I'm not sure how that applied.
[02:20] <jamesh> applies, even
[02:20] <mpt> it's how to stop a link from going somewhere
[02:20] <mpt> "Add a comment to this bug" is a link that goes somewhere, but shouldn't take effect
[02:23] <jamesh> mpt: currently the code is being hooked up with addEventListener(), and the callback cancels the default action with event.preventDefault()
[02:32] <SteveA> bug 6466
[02:32] <Ubugtu> Malone bug 6466: "apply underlining of links according to the rules" Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Matthew Paul Thomas, Status: Accepted http://launchpad.net/bugs/6466
[02:40] <daf> is there a way to run a single page test?
[02:41] <SteveA> it's in the hacking faq i think
[02:41] <SteveA>   python test.py --test NAME
[02:41] <daf> I cna't find it there
[02:41] <daf> aha
[02:46] <daf> SteveA: hmm, that doesn't seem to work
[02:46] <daf> it doesn't run any tests
[02:46] <daf> when I give it the name of a page test
[02:48] <SteveA> .txt too
[02:48] <daf> oh, it doesn't find tests lib/canonical/launchpad/pagetests
[02:48] <daf> only those in lib/canonical/launchpad/pagetests/*/
[02:49] <daf> this implies that xx-shipit-reports.txt is not being run
[02:50] <stub> bradb: What is the issue with the targetnamecache?
[02:50] <bradb> stub: Can we do substring searching on it without killing the search pages?
[02:51] <bradb> stub: ISTR you saying that it might work for a while, but that doesn't seem an ideal assessment to move forward with. :)
[02:51] <stub> Right now, yes. It might start giving issues as the number of bugs increases.
[02:52] <stub> We can test it on staging with the bugzilla database migrated.
[02:52] <bradb> ok
[02:53] <stub> My gut feeling is that it will be fine until around 30 or 40k bugs.
[02:53] <bradb> stub: So just a simple OR + ILIKE tacked onto the search query, or is there a faster way to spell this?
[02:53] <stub> But that is really just a guess
[02:53] <bradb> s/OR/AND/
[02:54] <stub> AND ILIKE tacked on the end will be best
[02:54] <stub> I think ;)
[02:54] <bradb> ok, I'll try that out, thanks
[03:05] <SynrG> someone referred me to a launchpad wiki page, and I saw errors on it, so I dutifully registered with launchpad using my preferred email (not my @debian.org email) to make the changes.  However, now i'm looking at my wiki UserPreferences page and it is for BenArmstrong2.  did i make a mistake? as a DD am I already registered? (presumably under synrg@debian.org?)
[03:05] <sivang> SynrG: Ben?? =)
[03:05] <SynrG> sivang: you have me at a disadvantage ... apparently you know me.  you are?
[03:06] <sivang> SynrG: You recall we talked once, I think on debian-mentors or something like that? about packaging stuff? =) I suppose you know ChrisH as well
[03:06] <sivang> man, that was a while back
[03:07] <SynrG> ah, ok.  you have a better memory than I :)
[03:07] <SynrG> and yes, #debian-mentors sounds about right
[03:07] <SynrG> and I do know ChrisH
[03:07] <sivang> :)
[03:08] <sivang> SynrG: regarding your issue, I think daf might know =)
[03:08] <sivang> (it's a known one)
[03:09] <SynrG> daf: I await your wisdom on this matter, then
[03:09] <daf> duplicate wiki pages?
[03:09] <daf> that implies that Launchpad already automatically registered you once
[03:10] <sivang> maybe due to some import attempts?
[03:10] <daf> probably through your Debian work
[03:10] <SynrG> by virtue of me being a DD?
[03:10] <kiko> people need to stop emailing me
[03:10] <SynrG> i don't recall initiating it myself
[03:10] <daf> it would have been automatic
[03:10] <SynrG> then i don't know my password
[03:10] <daf> all you need to do is find the account and merge it with the one you registered
[03:11] <SynrG> ah
[03:11] <daf> https://launchpad.net/people/?name=ben+armstrong&searchfor=peopleonly
[03:11] <sivang> daf: I wonder if this is in the launchpad FAQ
[03:12] <daf> sivang: it should be
[03:13] <sivang> hmm , searching for FAQ gives :
[03:13] <sivang>    1. LaunchpadHackingFAQ
[03:13] <sivang>    2. LaunchpadProductionFAQ
[03:13] <sivang>    3. LaunchpadTeamFAQ
[03:13] <daf> SynrG: the forgotten password feature won't work for the automatically created account, since it has no registered emails
[03:13] <daf> sivang: time to create one, then :)
[03:13] <sivang> TeamFAQ is the user's one? :-)
[03:13] <sivang> ok then, off I go to do that!
[03:13] <kiko> I'm going to try and stick more memory in this little box
[03:13] <kiko> bbiab
[03:13] <SynrG> daf: ah.  then ... to merge?
[03:13] <daf> SynrG: https://launchpad.net/people/+requestmerge/
[03:13] <SynrG> daf: i see both of me at the URL you pasted above
[03:14] <daf> ah, hmm
[03:14] <daf> that won't work
[03:14] <daf> since you need email for that too
[03:15] <daf> aha, but with my special admin powers I can give the other account an email address
[03:15] <daf> Launchpad suggests synrg@sanctuary.nslug.ns.ca
[03:15] <daf> but I can add any one you like
[03:16] <SynrG> that address is the one i use on all packages.
[03:16] <SynrG> the dup account is synergism@gmail.com
[03:16] <SynrG> i use that for personal use, web registrations, etc.
[03:17] <SynrG> so yes, assign synrg@sanctuary.nslug.ns.ca -> synrg
[03:17] <daf> ok, you should get an email asking you to confirm the nslug address
[03:17] <SynrG> and then i can merge
[03:17] <daf> cool
[03:17] <daf> you may want to recover a password for the synrg account and then merge synergism with it
[03:18] <daf> rather than the other way around
[03:18] <daf> up to you
[03:18] <SynrG> and in the merge, which wikiname becomes mine?
[03:18] <SynrG> ok
[03:18] <SynrG> so this makes BenArmstrong2 go away
[03:18] <SynrG> if done in that order
[03:18] <daf> I think so
[03:18] <SynrG> that's what I want. thanks.
[03:18] <daf> if not, I'm sure we can fix it
[03:18] <SynrG> ok
[03:18] <daf> sivang: looks like there isn't a user FAQ
[03:18] <daf> sivang: there should be, I think
[03:20] <sivang> daf: I wonder how many question we already missed :-/ , that should be there..presumably some good deal of those will pop up on launchpad-users
[03:21] <SynrG> hm.  it has to get past postgrey first.
[03:21] <daf> sivang: do you feel like creating it and adding a question about wiki names with numbers on?
[03:21] <kiko> sivang, if I ever get around to announcing the list, you mean
[03:21] <daf> what's blocking you, kiko?
[03:22] <kiko> I'm not sure.. an attitude?
[03:22] <daf> you have an attitude problem?
[03:22] <kiko> I need to get my work under control right now I'm riding the hurricane
[03:22] <kiko> inbox out of control
[03:22] <kiko> thousands of threads to read on launchpad lists
[03:22] <kiko> etc
[03:22] <daf> whoosh
[03:22] <kiko> the rain depresses me further
[03:23] <kiko> anyway, I'll move on with this
[03:23] <daf> poor kiko
[03:23] <kiko> memory upgrade
[03:23] <kiko> or attempted memory ugrade
[03:23] <kiko> it involves using putty knives
[03:23] <daf> !
[03:23] <kiko> you have something against putty knives?
[03:24] <daf> I have reservations about sticking putty knives into computers
[03:24] <kiko> we've all got our prejudices
[03:25] <daf> did it have putty on it?
[03:25] <sivang> kiko: want me to announce it? where should we announce it anywyas?
[03:26] <sivang> it could get worse - you could be living in the middle east :-D
[03:27] <kiko> hardly
[03:28] <sivang> speaking of which, are you still planning to visit here on Feb?
[03:29] <dilys> Merge to devel/launchpad: [r=jamesh]  fix bug 2230 by adding a redirect (r2953: Dafydd Harries)
[03:30] <sabdfl> ddaa: i was using APT as an example of an upstream that's already in bzr
[03:40] <SynrG> daf: while impatiently waiting for the confirmation, i checked my mail logs.  glad i did.  i was being hammered by three IP#s which I've now banned at the router. :P
[03:41] <SynrG> daf: hah.  this isn't going to work :)
[03:41] <SynrG> To confirm this address, enter your password.
[03:41] <SynrG> so .. to set my password i need an email address ...
[03:41] <SynrG> but to set my email address, i need my password ...
[03:42] <SynrG> :P
[03:44] <SynrG> ah, but the forgotten password link does work!
[03:45] <SynrG> and after filling it in, and returning to the validate email link, i see:
[03:45] <SynrG> This email address is already registered and validated for your Launchpad account. There's no need to validate it again.
[03:45] <SynrG> so, all is good
[03:45] <SynrG> daf: thanks
[03:45] <daf> no problem
[03:55] <SynrG> and now merged OK
[03:55] <SynrG> now to finally edit the wiki.  whew.
[03:56] <sivang> daf: I haven't been watching to conversation till now, is this always requires manual lauchpad admin intervention, or can we have this our first FAQ item?
[03:59] <sivang> daf: I will do that (responding to your previous question)
[04:01] <daf> I think the short answer is... it's complicated
[04:02] <daf> due to the fact that many accounts that people want to merge don't have email addresses
[04:02] <daf> which prevents merging them
[04:02] <sivang> ok, so we add a note there that one must contact a launchpad admin to sort that out?
[04:03] <sivang> and then outline the procedure?
[04:03] <sivang> (e.g. what SynrG had to do on his own regardless of your launchpad admin intervention)
[04:03] <SynrG> daf: erhm, not all OK.  wiki password doesn't match
[04:04] <SynrG> daf: and wiki isn't providing me with an option to mail me my password (email not set?)
[04:06] <sivang> SynrG: what are you trying to edit btw?
[04:07] <kiko> SynrG, the wikis accounts are really managed via launchpad
[04:08] <SynrG> https://wiki.ubuntu.com/ContributingToDebian
[04:11] <SynrG> oops.  should've checked "trivial change"
[04:11] <SynrG> oh well.  too late.
[04:11] <SynrG> next time i will
[04:15] <SynrG> so, i'm stuck.
[04:15] <SynrG> even with dashboard i can't fix this.  the wiki doesn't know about my email address
[04:15] <SynrG> so i can't subscribe to wiki pages
[04:16] <SynrG> or edit wiki UserPreferences
[04:20] <daf> hmm
[04:20] <daf> the wiki uses the same password as Launchpad
[04:24] <SynrG> Passwords don't match!
[04:24] <SynrG> Clear message
[04:24] <SynrG> i know i have typed it correctly.  this is about the fourth try
[04:25] <SynrG> same password as I used to login to launchpad (confirmed a few times, as I have logged in & logged out of launchpad)
[04:25] <SynrG> meanwhile, i've updated some other dashboard things: gpg key validated, etc.
[04:33] <daf> hmmm, maybe the wiki thinks you're trying to change your password
[04:38] <daf> moin is clever like that
[04:40] <SynrG> daf: clever in what sense?  like: oh what a clever girl, joanna, your crayon wall mural is magnificent! ?
[04:41] <SynrG> i need admin intervention, please
[04:41] <kiko> lol
[04:41] <kiko> SynrG, what are you trying to do?
[04:44] <SynrG> change something, anything, in my UserPreferences on the wiki
[04:44] <SynrG> the wiki refuses to allow me, using my dashboard password
[04:45] <SynrG> also, it refuses to mail me my password because it doesn't even present me with a link ...
[04:45] <SynrG> and tells me that i haven't got an email address
[04:45] <SynrG> whereas dashboard currently knows two email addresses for me
[04:47] <SynrG> e.g. if i try to subscribe to a page, the wiki tells me i have no email address
[04:48] <daf> hmm
[04:48] <daf> and you're logged in to the wiki?
[04:49] <SynrG> daf: apparently
[04:49] <daf> how odd
[04:49] <SynrG> the top bar has a link to my name, at least
[04:50] <SynrG> that would suggest i'm logged in
[04:50] <daf> which email address did you use to log in?
[04:50] <daf> yes, that does suggest you're logged in
[04:50] <SynrG> either one.  they're both broken
[04:51] <daf> ok
[04:51] <daf> either one should work
[04:52] <daf> since you can log into launchpad, that suggests that your account basically works
[04:52] <SynrG> yes.
[04:52] <SynrG> and i've just confirmed again.  logging in with either email address breaks.
[04:52] <SynrG> so something about how you set the email address broke, i guess.
[04:52] <daf> does it still say "Passwords don't match!"?
[04:52] <SynrG> yes, it does.
[04:53] <SynrG> remember, when you set the email address i was emailed to confirm
[04:53] <daf> right
[04:53] <SynrG> but it wouldn't allow me to confirm because that required a login
[04:53] <daf> which of course you didn't have
[04:53] <SynrG> so i filled out the forgotten password page
[04:53] <SynrG> it obliged
[04:53] <SynrG> i filled that out
[04:53] <SynrG> then it wouldn't allow me to finish the email address change confirmation
[04:54] <SynrG> told me it was already confirmed
[04:54] <daf> bizarre
[04:54] <daf> by the way, which wiki are you logging in to?
[04:55] <SynrG> wiki.ubuntu.com
[04:55] <SynrG> the URL to the page i edited is above, about 40 minutes back
[04:56] <SynrG> i successfully edited it, btw
[04:57] <daf> hmm, if I try to log into the wiki with a wrong password, it says "Sorry, wrong password.
[04:57] <daf> this is on https://wiki.ubuntu.com/UserPreferences
[04:57] <kiko-fud>  5119 kiko      25   0  182m 174m 2940 R 98.4 17.3  50:37.05 bzr                                       
[04:57] <kiko-fud> 200mb of bzr
[04:57] <kiko-fud> love's a gig
[04:57] <kiko-fud> food time
[04:58] <SynrG> ah, but it can't be wrong.  i've logged in and out of dashboard, each time successfully, and several attempts to the wiki, each time with the same password.  dashboard allows me in.  the wiki does not.
[04:58] <SynrG> therefore, the passwords must differ
[04:59] <SynrG> something which dashboard should not permit
[04:59] <daf> if you go to the UserPreferences page on the wiki, does it give you a Logout button near the bottom?
[04:59] <kiko-fud> dashboard?
[04:59] <daf> kiko-fud: /people/synrg, I think
[04:59] <SynrG> s/dashboard/launchpad/ of course
[05:01] <daf> I need to go out
[05:01] <SynrG> yes. after clicking on that i now see where i can try mail me account data
[05:01] <daf> back later
[05:01] <SynrG> i will try that
[05:01] <SynrG> thanks
[05:02] <SynrG> ah.  it just requests that i use launchpad's forgotten password page instead
[05:08] <sivang> how do you spell "mucho" for "alot" in spanish?
[05:10] <gneuman> mucho
[05:11] <sivang> gneuman: thanks :)
[05:11] <SynrG> by the way, "alot" is neither spanish nor english :)
[05:19] <gneuman> sivang, np
[05:38] <dilys> Merge to devel/launchpad: Provide a URL to get view the bugs associated with a particular remote bug, fixing bug 4120, r=BjornT (r2954: James Henstridge)
[06:50] <bradb_> kiko-fud: The substring package name search test + fix is in pqm's queue.
[07:13] <kiko-fud> bradb_, really? rock and roll!
[07:13] <kiko-fud> wow
[07:13] <kiko-fud> that's pretty amazing turnover, bradb_ 
[07:27] <bradb_> kiko: thanks :)
[07:44] <kiko> guys
[07:44] <kiko> is the codec bug in bzr solved in a recent version?
[07:45] <ddaa> I'm almost certain it's fixed in the dailies
[07:45] <kiko> remind me what the repository for them is, ddaa?
[07:46] <ddaa> release-process wise they seem to have a problem: set too high requirements for the next minor.
[07:46] <kiko> we've all got our prejudices
[07:48] <ddaa> deb http://people.ubuntu.com/~jbailey/snapshot/bzr/ ./
[07:49] <kiko> thanks
[07:49] <ddaa> bzr is mpool's, bzr-integration is lifeless'
[07:50] <kiko> what's the difference
[07:50] <ddaa> which is one is the "best" depends on weather, oil prices, and middle east events.
[07:54] <LarstiQ> sharon has been tipping the balance to integration
[07:55] <kiko> he's been tipping into hospital, more realistically
[07:57] <SteveA> in my more grandiose moments, i've thought of launchpad as a medium for political and social change
[07:57] <SteveA> for example, simply create the Middle East project, containing Israel and Palestine products
[07:57] <SteveA> and file bugs accordingly
[07:57] <SteveA> no problems
[07:58] <kiko> is that what the word "grandiose" means?
[07:58] <ddaa> Let's start by  creating a GNU project, a Emacs product, and two series: "main" and "xemacs" :)
[07:59] <kiko> I didn't think it meant "mentally incapacitated"
[08:07] <kiko> hey sabdf1 
[08:07] <kiko> are you mark's evil twin?
[08:21] <kiko> hey bradb 
[08:21] <kiko> and BjornT 
[08:21] <bradb> kiko: hi
[08:21] <kiko> are you guys aware of the warning that process-mail is raising?
[08:21] <bradb> kiko: No.
[08:21] <kiko> +DeprecationWarning: IBugTask.maintainer was deprecated as part of InitialBugContacts. Talk to bradb
[08:21] <kiko> +about removing this completely from the UI and data model.
[08:21] <kiko>   "completely from the UI and data model.", DeprecationWarning)
[08:22] <bradb> Oh, that's me.
[08:22] <kiko> in components/bugtask.py
[08:22] <bradb> I'll take that out right now.
[08:22] <kiko> sure
[08:22] <kiko> you don't want to fix the callsite instead?
[08:23] <bradb> kiko: The issue is that IBugTask.maintainer shouldn't really exist, because it serves to clear purpose.
[08:23] <kiko> correct
[08:23] <kiko> so fix the callsite, right?
[08:23] <bradb> So, when I say, "I'll take that out", I mean removing IBugTask.maintainer and, of course, callsites.
[08:23] <ddaa> you mean, like slashdot?
[08:24] <ddaa> (serves no clear purpose)
[08:24] <kiko> ddaa, slashdot provides you with news that matters!
[08:24] <bradb> I'll do it on a separate branch actually.
[08:24] <bradb> Slashdot is almost as useful as digg.
[08:24] <ddaa> Oh, I'll use something else then...
[08:25] <ddaa> like the whitespace that takes 50% of the horizontal space of most launchhpad pages?
[08:25] <ddaa> yeah, that's better troll matter :)
[08:26] <kiko> whitespace is an asset
[08:26] <kiko> we can use it to sell adverts when we are the most important site on the internet
[08:26] <ddaa> kiko: I'll go make conversation with King Kong, or Narnia, I think... cya
[08:52] <dilys> Merge to devel/launchpad: [trivial]  Fix https://launchpad.net/products/malone/+bug/1440 (r2955: Brad Bollenbach)
[10:11] <Yann2> hi :)
[10:12] <Yann2> i'm confronted to (I think) a quite annoyant bug with launchpad
[10:12] <SteveA> hello yann
[10:12] <SteveA> what's up?
[10:12] <Yann2> it seems that every time "Yann" (on launchpad) subscribes to a bug, I (Yann Hamon on lauchpad) get automatically subscribed too
[10:13] <SteveA> that's interesting.  i'll take a look...
[10:13] <Yann2> is it possible? :)
[10:13] <Yann2> https://launchpad.net/distros/ubuntu/+source/fte/+bug/6476
[10:13] <Yann2> for example
[10:13] <Ubugtu> Malone bug 6476: "fte: merge new debian version" Fix req. for: fte (Ubuntu), Severity: Normal, Assigned to: MOTU Merge Team, Status: Fixed http://launchpad.net/bugs/6476
[10:14] <SteveA> kiko: front page of staging is timing out :-(
[10:15] <SteveA> kiko: possibly every page on staging is timing out :-(
[10:15] <kiko> this is depressing indeed
[10:15] <SteveA>     *
[10:15] <SteveA> RequestExpired: (('SELECT COUNT(*) FROM TeamParticipation WHERE person = 74 AND team = 100',), {})
[10:18] <lifeless> only reason that should be slow is locked tables
[10:19] <SteveA> it may be another query before it is almost too slow
[10:19] <SteveA> and this one was the last straw
[10:19] <SteveA> BjornT: is it possible for me to unsubscribe someone from a bug?
[10:19] <SteveA> Yann2: i've looked into it, and all i can think of is this
[10:20] <SteveA> Yann2: the user yann-pleiades tries to subscribe himself, and types in "yann" into the subscription UI.  Then, he sees that you, not he, is subscribed.  He cannot unsubscribe you, so he just subscribes himself anyway.
[10:20] <kiko> lol
[10:20] <kiko> it didn't time out for me
[10:20] <SteveA> one solution is that you change your launchpad-name to yann-something rather than just 'yann'
[10:20] <Yann2> SteveA > mmh, fact is, i nevere subscribed to any of these bugs :D
[10:21] <SteveA> yes
[10:21] <Yann2> i am yann hamon not yann =)
[10:21] <SteveA> i think yann-plieades subscribed you by mistake
[10:21] <kiko> you can subscribe others, but not unsubscribe them
[10:21] <Yann2> mmh
[10:21] <Yann2> i'll have a look ^^
[10:21] <SteveA> your name in launchpad is simply "yann", in the URL
[10:21] <kiko> the proper fix for this is probably not having CC subscriptions and doing that mpt suggested.
[10:21] <kiko> forwarding bug reports.
[10:21] <Yann2> oh.
[10:21] <kiko> of course
[10:22] <Yann2> actually, yes. hey, cool 8-) :D
[10:22] <kiko> salgado's report from a while back already pointed out this problem -- our user matching is too transparent
[10:22] <SteveA> transparent?
[10:22] <kiko> well
[10:22] <SteveA> naive?
[10:22] <Yann2> so hm, what would you suggest? :)
[10:23] <kiko> yeah. it assumes that a single match is a sign it's found a sure bet, when that's not the truth in cases like the above.
[10:23] <Yann2> yann-hamon as name instead of yann?
[10:23] <SteveA> Yann2: change your "name" (as in what is in the URL) to yann-hamon
[10:23] <SteveA> yes
[10:23] <Yann2> ok
[10:23] <Yann2> here ends my endell hopes of an yann@ubuntu.com email adress :'(
[10:23] <SteveA> i'm stevea in launchpad
[10:23] <Yann2> -endell +endless
[10:23] <SteveA> rather than "steve"
[10:24] <Yann2> letz take yannh :)
[10:24] <kiko> right
[10:24] <Yann2> https://launchpad.net/people/yannh
[10:24] <Yann2> :)
[10:24] <SteveA> cool
[10:25] <Yann2> thanks for help ;)
[10:25] <lifeless> SteveA: is the timeout problem going on now ?
[10:29] <SteveA> https://staging.ubuntu.com/  i'm logged in, times out, OOPS-5S12
[10:30] <SteveA> i logged out
[10:30] <SteveA> it work
[10:30] <SteveA> s
[10:30] <SteveA> what's it doing when i'm logged in, that makes it take so much time?
[10:30] <SteveA> perhaps a flaw in the traceback-display-decision code?
[10:31] <SteveA> i am logged in again
[10:31] <SteveA> it is working now
[10:32] <SteveA> how odd
[10:32] <lifeless> so
[10:33] <SteveA> RequestExpired: (('SELECT COUNT(*) FROM Bounty WHERE 1 = 1',), {})
[10:33] <lifeless> there was a 448ms instance of that query that timed out
[10:33] <SteveA> that is from OOPS-5S12
[10:34] <Yann2> well, thanks SteveA ... bye :)
[10:35] <dilys> Merge to devel/launchpad: First round of the implementation of MirrorManagement. r=lifeless (r2956: Guilherme Salgado)
[10:37] <lifeless> SteveA: interesting :
[10:37] <lifeless> <launchpad_staging/launchpad 17203 2006-01-05 21:31:00 GMT>LOG:  statement: SELECT COUNT(*) FROM Bounty WHERE 1 = 1
[10:37] <lifeless> <launchpad_staging/launchpad 17203 2006-01-05 21:31:00 GMT>LOG:  duration: 0.299 ms
[10:37] <lifeless> <launchpad_staging/launchpad 17197 2006-01-05 21:31:59 GMT>LOG:  statement: SELECT COUNT(*) FROM Bounty WHERE 1 = 1
[10:37] <lifeless> <launchpad_staging/launchpad 17197 2006-01-05 21:31:59 GMT>LOG:  duration: 12.200 ms
[10:38] <lifeless> and earlier still
[10:38] <lifeless> <launchpad_staging/launchpad 17203 2006-01-05 21:30:08 GMT>LOG:  statement: SELECT COUNT(*) FROM Bounty WHERE 1 = 1
[10:38] <lifeless> <launchpad_staging/gina 6137 2006-01-05 21:30:09 GMT>LOG:  duration: 355.126 ms
[10:38] <lifeless> this is a huge variation in time
[10:38] <SteveA> that's very odd
[10:39] <lifeless> oh, that lastone is mimatched I think
[10:39] <SteveA> but also, counting the bounties seems to take a long time
[10:39] <SteveA> i would have expected it to take less time than that
[10:39] <SteveA> oh, it is ms
[10:39] <lifeless> yes, the last one was not paired right, dual connections logging at once
[10:39] <SteveA> so, 0.299 ms is okay
[10:40] <SteveA> when jamesh has landed the "record all queries in this request plus times when filing an OOPS" code
[10:40] <SteveA> we'll be able to better understand what caused the problem
[10:41] <lifeless> yes
[10:50] <lifeless> ddaa: ping
[11:58] <mpt> Gooooooooooooooooooooood morning Launchpadders!
[11:58] <SteveA_> good morning mpt
[11:59] <kiko> hey mpt
[11:59] <mpt> hi kiko, you at Async or at home?
[11:59] <kiko> at async
[11:59] <mpt> ok, shall I call you there?
[11:59] <kiko> hmmm
[12:00] <kiko> will you be available in 12h?
[12:00] <kiko> I'd rather talk then if possible, I'm overstretched today
[12:00] <mpt> midnight, hmmm
[12:00] <kiko> otherwise let's do it now
[12:00] <mpt> I could stay up
[12:00] <mpt> that's fine
[12:00] <kiko> okay, cool.
[12:00] <kiko> msg me what number I should dial?