[12:26] <danilos> jordi: thanks, got it, but it seems to be only a single mail in it instead of the "bunch"
[01:19] <kiko> bradb, r=kiko on that patch.
[01:30] <lbm> the translations queue seems enormous, when can i expect a pot file to be accepted?
[01:31] <kiko> lbm, I think it's only enormous because edgy is being held back -- upstream imports are being processed quickly
[01:33] <lbm> okay, thanks kiko 
[01:34] <jordi> danilos: ok :P
[01:38] <jordi> danilos: just sent you another email with some stuff
[01:40] <jordi> danilos: do you have enough info for xaralx now?
[01:41] <jordi> kiko!
[01:47] <kiko> jordi, danilos: can you tell me about this "allow-universe-to-be-translated-in-Rosetta" change that happened this month?
[01:49] <danilos> jordi: I don't think I do; your forwarded email contained only once, and now I am stuck with a hot potato with both carlos and you on vacations ;)
[01:49] <danilos> kiko: nothing I know of
[01:51] <danilos> anyway, now really off to sleep, will try to handle all of these things (I'll simply ask the xaraxl maintainer again for all the names, or I'll wait for carlos)
[02:15] <bradb> kiko: cool, thanks
[02:15] <kiko> bradb, welcome
[05:00] <mpt> Gooooooooooooooood afternoon Launchpadders!
[05:09] <mpt> stub, thanks for finishing the DatabaseSchemaChanges page
[05:31] <stub> np
[08:35] <sabdfl> mpt: very good competitive analysis, great work
[08:50] <SteveA> morning
[09:07] <sivang> morning !
[09:15] <mpt> sabdfl, thanks
[09:56] <jamesh> morning ddaa 
[09:57] <ddaa> Mornig jamesh
[09:57] <ddaa> mpool: morning
[09:58] <ddaa> jamesh: I think you should not start checking whether the token looks like a plausible branch URL because it breaks DNRY
[09:58] <jamesh> DNRY?
[09:58] <ddaa> Do Not Repeat Yourself
[09:59] <jamesh> are you suggesting to just look it up as a unique name and fall back to look up as a URL otherwise?
[09:59] <jamesh> (or vice versa?
[10:00] <ddaa> Actually...
[10:00] <ddaa> Mh...
[10:00] <ddaa> I thought doinf what you just said, but it causes a relatively costly failure when the token in invalid
[10:02] <ddaa> But yes, getByUniqueName followed by getByUrl is cheap when it works.
[10:02] <ddaa> And it should remain correct forever even if we start supporting things like souk://
[10:03] <jamesh> if getByUrl() failed early for things that didn't look like a URL, it would be pretty cheap to put the URL check first
[10:05] <ddaa> I think a bit difficult to define, but there might be a way of saying "acceptable URL" in a way that prevents duplication
[10:05] <jamesh> well
[10:06] <jamesh> there is a validator for the IBranch.url field
[10:06] <jamesh> if we're looking up the registered URL of a branch, it should validate against that, right?
[10:06] <ddaa> Right.
[10:08] <ddaa> Well, this shortcut is not strictly necessary to getByUrl
[10:08] <ddaa> it only serves the purpose of making it cheap to getByToken in both success and failure cases
[10:09] <ddaa> Maybe you should actually add Branch.getByToken?
[10:09] <ddaa> And say that we care to make that as cheap as possible.
[10:10] <jamesh> getTermByToken() isn't called that much, iirc
[10:11] <ddaa> it's about locality and context
[10:11] <ddaa> not code reuse
[10:11] <ddaa> Anyway, I really just care about DNRY
[10:12] <ddaa> otherwise, what you do sounds just fine
[10:12] <ddaa> Oh right, you mean "not that much, so it's not performance critical"
[10:13] <ddaa> It might become more critical when we do the Ajax stuff SteveA wants
[10:14] <ddaa> But that may well be YAGNI
[10:15] <ddaa> jamesh: I want to have a preimpl voice with you today about the "put cscvs source trees on a central server" thing (importd-source-repo) today
[10:15] <jamesh> ddaa: gar.  I left my headset at the hotel.
[10:16] <ddaa> or maybe I should ask lifeless, he's got the required expertise
[10:16] <ddaa> but maybe not the time
[10:16] <ddaa> You can ask SteveA or BjornT if any is close by.
[10:17] <ddaa> But first, I need to find mpool about planning
[10:20] <jamesh> ddaa: looking at the code, getByUniqueName() is very cheap if the token does not begin with "~".  In the non-matching case, we'd usually just do one lookup by Branch.url
[10:20] <jamesh> which should be pretty cheap, and doesn't require any special knowledge of the supported branch URL schemes
[10:20] <jamesh> how does that sound?
[10:20] <ddaa> It's expensive to do that if the name looks like a valid unique but has the wrong values
[10:21] <ddaa> Then you end up doing one query in getByUniqueName, and one in getByUrl
[10:22] <jamesh> sure, but getByUniqueName() only does its thing if the token looks like "~xxx/xxx/xxx"
[10:22] <jamesh> URLs don't match that pattern, so getByUniqueName() exits early after the regexp match fails
[10:22] <ddaa> It would make sense to use the Branch.url validator to guard the Branch.selectOneBy(url=url), then either way is at most one query in all cases.
[10:23] <lifeless> ddaa: ?
[10:23] <lifeless> ddaa: I have 7 minutes
[10:24] <lifeless> ddaa: to answer your question about the symlink test I suggested jamesh write its a smoke-test
[10:24] <lifeless> symlinks are a feature, we should ensure they work end to end, even if we dont test them for every implementation end to end
[10:24] <lifeless> previously there were no tests that tested symlinks end to end
[10:24] <ddaa> Specifically, what feature did you intend to get tested?
[10:24] <ddaa> That you can import something that creates a symlink and that you find it in a fresh checkout of the import?
[10:25] <lifeless> that a symlink in a svn tree could be imported to a symlink supporting backend 
[10:25] <ddaa> lifeless: as you already pointed out to me "smoke 
[10:25] <ddaa> test" is a bit vague a term :)
[10:25] <lifeless> the idea of a smoke test is that if it fails you know theres smoke...
[10:25] <lifeless> and where theres some there is fire
[10:25] <ddaa> lifeless: ack that, I'll trim down the end-to-end test next time I get close to that code
[10:26] <lifeless> anyhow, the point is there are 2 interfaces in use: ISourceBranch and ITargetBranch :)
[10:26] <ddaa> Absolutely.
[10:27] <lifeless> this was the only test that tested a symlink could start in ISourceBranch and end in ITargetBranch. Other tests are needed to check for corners etc within each interface implementation
[10:27] <ddaa> Unfortunately, that kind of cleanup is somewhere down in the "might do it one day if I'm bored" section of my todo list.
[10:27] <lifeless> so what can I help yoi with today?
[10:28] <ddaa> It's a bit painful to do a lot of typing with that keyboard. Essentially, I need voice preimpl with you or jamesh about importd uploading and retrieving cscvs source trees from a central server,
[10:29] <ddaa> That will help many things in the end.
[10:29] <lifeless> ok
[10:29] <lifeless> take care of your hand
[10:29] <lifeless> talk with jamesh
[10:29] <lifeless> I will email you cc'd launcpad with a brane dump tomorrow 
[10:29] <ddaa> about?
[10:30] <lifeless> we've talked copying the trees around before
[10:30] <jamesh> ddaa: I'll go up to the hotel now and get my headset.  Be back soon.
[10:30] <lifeless> I have to go now - birthday dinner with Lynne
[10:30] <ddaa> cya
[10:30] <mpt_> meh
[10:30] <mpt_> How do I get the width and height of a window?
[10:30] <mpt_> I thought xprop did that, but it doesn't seem to
[10:30] <lifeless> byby
[10:34] <mpt_> ah, xwininfo
[10:50] <RicardoPerez> hi. is it a rosetta-specific channel?
[10:51] <jamesh> ddaa: back
[10:52] <ddaa> Okay, no mpool in sight. I'll set up my voip.
[10:52] <jamesh> do we try canonical voip, or skype?
[10:53] <ddaa> canonical voip worked okay for me last time I tried
[10:53] <ddaa> and I haven't use skype in a while
[10:53] <ddaa> so, canonical voip, please
[10:54] <RicardoPerez> sorry.... by the way.... what is "canonical voip"?
[10:55] <ddaa> corporate asterix server
[10:55] <RicardoPerez> oh, ok... I wonder if it's public or private...
[10:55] <ddaa> corporate = private
[10:56] <RicardoPerez> ok, ok, thanks a lot
[10:57] <mdke> RicardoPerez: this is the right channel for asking about rosetta.
[10:57] <RicardoPerez> mdke: oh, great. I think there's an error in the langpacks generation
[10:58] <RicardoPerez> mdke: I think the langpacks generation procedure is using obsolete Rosetta's templates
[10:59] <mdke> maybe pitti in #ubuntu-devel can help you about that
[10:59] <jamesh> ddaa: I hit your voice mail, but the voice quality was pretty bad
[10:59] <RicardoPerez> mdke: ok, I'll try it. thanks a lot
[11:00] <jamesh> ddaa: are you set up yet?
[11:00] <ddaa> Mostly
[11:00] <ddaa> Ready
[11:00] <jamesh> I'll dial you then
[11:01] <ddaa> way too much cutoff
[11:01] <jamesh> I couldn't make out what you were saying either
[11:01] <ddaa> f
[11:02] <ddaa> Sounds like ekiga could use the ability to add some redundancy to the streams
[11:02] <ddaa> I'll set up skype
[11:11] <dsas> Could someone tell me how to remove bug watches? The ones displayed in the left hand panel.
[11:13] <SteveA> dsas: I don't think you can.
[11:14] <dsas> oh, should I file a bug?
[11:14] <ddaa> jamesh: I'm set up
[11:15] <ddaa> david.allouche
[11:15] <SteveA> dsas: maybe there is one already.  But also, BjornT or bradb may know about it.
[11:15] <SteveA> dsas: what watch do you want to remove?
[11:15] <dsas> https://launchpad.net/products/epiphany/+bug/50973 I want to keep the gnome-bugs 349767 bug and drop the others
[11:15] <Ubugtu> Malone bug 50973 in epiphany "Tooltips linger annoying after changing desktops." [Unknown,Unknown]  
[11:16] <dsas> (I typed the wrong bug number in by mistake, then mistakenly filed the proper bug number against the wrong tracker)
[11:17] <BjornT> dsas: bug 3140
[11:17] <Ubugtu> Malone bug 3140 in malone "Bug watches can't be removed" [Medium,Confirmed]  http://launchpad.net/bugs/3140
[11:17] <dsas> BjornT: thanks
[11:31] <jamesh> ddaa: should I try calling you again on ekiga yet?
[11:32] <ddaa> I'm connected on v.c.c
[11:38] <dsas> Does the product name in a bug task have to match the upstream product name if the product is tracked in an upstream bugzilla?
[11:39] <dsas> for example the epiphany web browser is epiphany-browser on ubuntu but epiphany upstream, there is also an unrelated epiphany ubuntu package.
[11:40] <dsas> e.g. in bug 29893
[11:40] <Ubugtu> Malone bug 29893 in epiphany "Epiphany only supports HTTP Local bookmarks" [Unknown,Unconfirmed]  http://launchpad.net/bugs/29893
[11:42] <mpt> dsas, no, because different distributions might package the same product under different names
[11:43] <mpt> So the product name couldn't possibly be the same as all the package names :-)
[11:44] <dsas> Sorry, I didn't ask properly. Does the product name in an upstream bug task, have to match the upstream bugzillas product name.
[11:46] <jamesh> dsas: no.
[11:46] <jamesh> dsas: they should hopefully refer to the same software though :)
[11:48] <dsas> how do you differentiate if two upstream products have the same name? All the bugs in https://launchpad.net/products/epiphany/+bugs belong to the web browser, but where would epiphany-the-game product bugs go?
[11:49] <jamesh> dsas: well, they'd need different names in Launchpad
[11:49] <jamesh> similar to how they need different package names inside a distribution
[11:50] <jamesh> what they call themselves elsewhere is not a concern here
[11:50] <jamesh> (although it is nice if the names match, so people recognise the products in LP)
[11:50] <dsas> jamesh: Ok, fair enough. Just wondering what would happen.
[11:51] <dsas> should I file a bug if a bug watch hasn't updated? The watch was created in February
[11:52] <jamesh> what is it a watch on?
[11:52] <dsas> epiphany in gnome bugzilla, bug 29893
[11:52] <Ubugtu> Malone bug 29893 in epiphany "Epiphany only supports HTTP Local bookmarks" [Unknown,Unconfirmed]  http://launchpad.net/bugs/29893
[11:53] <jamesh> we've got a bug report open on this issue
[11:53] <jamesh> https://launchpad.net/products/malone/+bug/54898
[11:53] <Ubugtu> Malone bug 54898 in malone "Multiple bug watches pointing to the same remote bug aren't updated" [Medium,In progress]  
[11:54] <jamesh> there are two bugs watching that remote bug: https://launchpad.net/malone/bugtrackers/gnome-bugs/330679
[11:56] <dsas> jamesh: Ok, thanks for all the explanations.
[11:56] <jamesh> once that bug gets fixed, your bug watch should update
[12:06] <mpool> ddaa: hi
[12:06] <ddaa> mpool: hello
[12:06] <mpool> ddaa: do we have a meeting now, or soon?
[12:07] <ddaa> welcome distraction, I was getting bored of preparing the meeting
[12:07] <ddaa> Bazaar meeting in 52 minutes
[12:07] <mpool> ok
[12:07] <ddaa> mpool: you wanted to talk about bazaar planning
[12:07] <mpool> yes, i did
[12:07] <ddaa> maybe we should have a call before the meeting
[12:08] <mpool> yep, do you have skype?
[12:08] <mpool> i was going to just call steve briefly - how about at x:35?
[12:09] <ddaa> I'd like it better in a couple of minutes
[12:09] <ddaa> as a break from meeting prep
[12:09] <mpool> ok
[12:09] <mpool> so on what technology?
[12:09] <ddaa> Skype is fine
[12:09] <ddaa> brb
[12:10] <SteveA> mpool: I'm ready on skype now
[12:11] <mpool> SteveA: can i talk to david first and you in 15 minutes?
[12:11] <SteveA> I'd rather talk with you now
[12:11] <SteveA> as I want to get this off my mental stack, and get on with other stuff
[12:11] <mpool> ddaa: ok, steve first
[12:57] <ddaa> mpool: sorry, was having lunch
[12:57] <ddaa> lifeless: jamesh: mpool: SteveA: meeting in 2 mins
[01:00] <mpool> ddaa: thanks, where?
[01:00] <ddaa> #launchpad-meeting
[01:59] <Kinnison> (Twenty packets and counting...
[01:59] <Kinnison> FIN minus fifteen seconds, sequence is okay)
[01:59] <malcc> Bot malcc raised MeetingNotStartedException at line 1645
[02:00] <SteveA> it's that time again
[02:00] <stub> here
[02:00] <Kinnison> s/again/of year/
[02:00] <kiko-zzz> me
[02:00] <SteveA> Welcome to this week's Launchpad meeting
[02:00] <salgado> here
[02:00] <bradb> moo
[02:00] <Kinnison> moo
[02:01] <flacoste> me
[02:01] <ddaa> here
[02:01] <mpt> me
[02:01] <SteveA> excusing those suffering from premature verbal ejaculations...
[02:01] <SteveA> who's here today?
[02:01] <malcc> Me
[02:01] <mpt> me
[02:01] <matsubara> me
[02:01] <BjornT> me
[02:01] <Kinnison> I'm not
[02:01] <Kinnison> Oh hang on
[02:01] <Kinnison> I am
[02:01] <mpt> It's easier for me if you just say "me", kthx :-)
[02:01] <Kinnison> me
[02:01] <bradb> me
[02:01] <kiko> me
[02:01] <SteveA> 
[02:01] <SteveA> == Agenda ==
[02:01] <SteveA>  * Roll call
[02:01] <SteveA>  * Agenda
[02:01] <SteveA>  * Next meeting
[02:01] <SteveA>  * Activity reports
[02:01] <SteveA>  * Actions from last meeting
[02:01] <danilos> me
[02:01] <salgado> me
[02:01] <SteveA>  * Oops report (Matsubara)
[02:01] <SteveA>  * Bug report report (mpt)
[02:01] <SteveA>  * Production and staging (Stuart)
[02:01] <SteveA>  * Launchpad 1.0 status reports
[02:02] <SteveA>  * Sysadmin requests
[02:02] <SteveA> ----
[02:02] <SteveA>  * Using email in a distributed team (Steve, Kiko)
[02:02] <SteveA>  * Python demo status update (James H)
[02:02] <SteveA>  * Tagging Launchpad bugs (bradb)
[02:02] <SteveA>  * (other items)
[02:02] <SteveA> ----
[02:02] <SteveA>  * Keep, Bag, Change
[02:02] <SteveA>  * Three sentences
[02:02] <SteveA> next meeting, same time next week
[02:02] <SteveA> * Activity reports
[02:02] <danilos> behind
[02:02] <mpt> up to date
[02:02] <stub> Up to date
[02:02] <SteveA> Who's up to date, and who is behind?
[02:02] <bradb> up to date
[02:02] <SteveA> behind
[02:02] <malcc> Up to date
[02:02] <matsubara> up to date
[02:02] <flacoste> up to date
[02:02] <salgado> up to date
[02:02] <Kinnison> behind
[02:02] <ddaa> up to date
[02:02] <malcc> Guilty of summarising
[02:02] <danilos> (this week missing)
[02:02] <BjornT> behind
[02:02] <jamesh> not up to date
[02:03] <kiko> up to date
[02:03] <SteveA> james and bjorn are sprinting
[02:03] <SteveA> in a mini sprint in vilnius
[02:04] <SteveA> so it's okay that they're behind
[02:04] <SteveA> well done to mpt, stub, bradb, matsubara, malcc
[02:04] <SteveA> flacoste, salgado, ddaa
[02:04] <SteveA> and kiko
[02:04] <kiko> thanks for remembering me steve
[02:04] <SteveA>  * Actions from last meeting
[02:04] <SteveA>  * SteveA to go through RT issues and chase elmo if appropriate
[02:05] <stub> I did that
[02:05] <SteveA> cool
[02:05] <SteveA> thanks stub
[02:05] <SteveA>  * Oops report (Matsubara)
[02:05] <matsubara> Today's oops report is about bugs 30602, 44860, 51750, 1558
[02:05] <Ubugtu> Malone bug 30602 in rosetta "ERROR IN: https://launchpad.net/distros/ubuntu/dapper/+source/vlc/+pots/vlc/tl/+translate" [Medium,Confirmed]  http://launchpad.net/bugs/30602
[02:05] <Ubugtu> Malone bug 44860 in rosetta "Crash when we try to pass a query string to a POFile that doesn't exist yet." [High,In progress]  http://launchpad.net/bugs/44860
[02:05] <Ubugtu> Malone bug 51750 in soyuz "Somehow got two buildqueue records with same builder." [High,In progress]  http://launchpad.net/bugs/51750
[02:05] <Ubugtu> Malone bug 1558 in rosetta "Export request form should check for uniqueness of entry" [Medium,Confirmed]  http://launchpad.net/bugs/1558
[02:05] <matsubara> danilos has two oops bugs on his plate. 30602 which is the top time out oops, so please prioritize it. And 44860 that is waiting for reply.
[02:05] <matsubara> cc last time I checked bug 51750 was almost ready. What happened to dogfood tests?
[02:05] <Ubugtu> Malone bug 51750 in soyuz "Somehow got two buildqueue records with same builder." [High,In progress]  http://launchpad.net/bugs/51750
[02:06] <matsubara> malcc: ^^
[02:06] <SteveA> kiko: shall we put 30602 up to a high importance?
[02:06] <danilos> matsubara: I haven't started on 30602 yet, will put more time into it
[02:06] <malcc> matsubara: Just got drowned in other things
[02:06] <matsubara> 1558 is assigned to carlos but I'll take over if nobody's complain.
[02:06] <danilos> matsubara: 44860 should be ready for pqm-submit today
[02:06] <cprov> here  and up to date
[02:06] <matsubara> thanks danilos 
[02:06] <kiko> SteveA, it's not trivial to fix unfortunately. it requires more deep thinking -- maybe danilo can get to it, but I suspect he'll drown in codepaths
[02:06] <SteveA> matsubara: carlos should be back shortly, but I don't think he'd complain.
[02:07] <matsubara> malcc: any chance of prioritizing it?
[02:07] <SteveA> kiko: does that have a bearing on the importance?
[02:07] <matsubara> malcc: I've seen most of the people affected by that bug are distro team guys
[02:07] <malcc> matsubara: I'll try, but you know what they say, once you've got more than eight priorities you've not really got any priorities
[02:07] <kiko> SteveA, I guess not.
[02:07] <kiko> matsubara, bump 30602 up in importance
[02:07] <danilos> kiko: I can try to handle it, and I'll be asking for lots of help, if that's fine with you guys :)
[02:08] <SteveA> kiko: who should work on 30602?  you?
[02:08] <matsubara> kiko: ok
[02:08] <Kinnison> malcc: priorit  droite
[02:08] <kiko> SteveA, I am going to fix +translations first
[02:08] <SteveA> how about kiko and danilos having a call about 30602 to talk through the code involved?
[02:09] <kiko> danilos, it involves rearchitecting, I suspect. I'm happy to guide you through it, but I need to do some research first. I guess we can research together -- have you ever used an OOPS log for perf work before?
[02:09] <matsubara> malcc: well, if the distro team is ok with that page crashing a lot I have no further complaints. :)
[02:09] <SteveA> kiko, danilos: rest of arrangements out of band please
[02:09] <ddaa> love that way of closing bugs
[02:09] <cprov> matsubara: they are not :(
[02:10] <danilos> kiko: sure; SteveA: ok, will do that (except that I need my VoIP details)
[02:10] <SteveA> danilos: be sure to mention the RT number later in this meeting
[02:10] <danilos> SteveA: don't worry, it's ready
[02:10] <SteveA> matsubara: I lost track.  any issues still not dealt with?
[02:11] <matsubara> kiko: can you help malcc re-prioritize some stuff so he can deal with 51750?
[02:11] <kiko> danilos, we can try IRC first if you like. anyway
[02:11] <matsubara> I'm done thanks SteveA 
[02:11] <danilos> kiko: np
[02:11] <kiko> matsubara, malcc's problem is that he has a deadline for more important stuff. I suggest cprov look at it, or someone else
[02:11] <SteveA> thank you matsubara.  that section of the meeting went smoothly.
[02:12] <lucasvo> we have an error: Launchpad could not mirror this branch at 2006-08-03 14:00:03 CEST.  The error was: Not a branch: /srv/sm-ng/push-branches/00/00/06/81/.bzr/branch/
[02:12] <kiko> I'd be happy to try and guide someone else into fixing it..
[02:12] <lucasvo> https://launchpad.net/people/harmony-dev/+branch/harmony/mailbox
[02:12] <SteveA>  * Bug report report (mpt)
[02:12] <mpt> Today's oldest most important open bugs are:
[02:12] <mpt>  * Bug 1294 (Filing a private bug requires the ability to Cc the maintainer), Critical, Fix Committed, bradb
[02:12] <mpt> bradb, have you verified it on production? If so, please mark it so
[02:12] <Ubugtu> Malone bug 1294 in malone "Filing a private bug requires the ability to Cc the maintainer" [Critical,Fix committed]  http://launchpad.net/bugs/1294
[02:12] <jamesh> lucasvo: can you wait til after the meeting?
[02:12] <mpt>  * Bug #2497 (/people/*/+translations times out for prolific translators), Critical, Confirmed, kiko
[02:12] <mpt> kiko?
[02:12] <matsubara> kiko: I'll nag you then so we can solve that. :)
[02:12] <Ubugtu> Malone bug 2497 in rosetta "/people/*/+translations times out for prolific translators" [Critical,Confirmed]  http://launchpad.net/bugs/2497
[02:12] <SteveA> lucasvo, ddaa: could you guys talk about this on #launchpad-meeting ?
[02:12] <mpt>  * Bug #31038 (private), Critical, In Progress, cprov
[02:12] <mpt>  * Bug #31609 (buildd maintainers need to be informed of build failures), Critical, In Progress, cprov
[02:12] <Ubugtu> Malone bug 31609 in soyuz "buildd maintainers need to be informed of build failures" [Critical,In progress]  http://launchpad.net/bugs/31609
[02:12] <mpt> cprov, will you get one of those fixed over the coming week?
[02:12] <lucasvo> sry, didn't want to interrupt the meeting
[02:12] <cprov> kiko: I've delivered 5 critical fixes and I want to be sure they will be rolled out next week befor starting anything else, I think I'm overloaded as well
[02:12] <mpt>  * Bug #35965 (exceptions in process-upload not communicated to uploader), Critical, Confirmed, malcc
[02:12] <kiko> mpt, yes, I know. I'll probably do so nooooow
[02:12] <mpt> malcc?
[02:12] <Ubugtu> Malone bug 35965 in soyuz "exceptions in process-upload not communicated to uploader" [Critical,Confirmed]  http://launchpad.net/bugs/35965
[02:13] <kiko> that's one of the bugs cprov is fixing mpt!
[02:13] <mpt> oh good
[02:13] <mpt> reassign it then :-)
[02:13] <kiko> cprov, yeah. matsubara, either you and I try fixing it, or wait.
[02:13] <mpt>  * Bug #37866 (+editstatus should not accept binary package as source package), Critical, Fix Committed, kiko
[02:13] <mpt> kiko, have you verified it on production? If so, please mark it so
[02:13] <Ubugtu> Malone bug 37866 in malone "+editstatus should not accept binary package as source package" [Critical,Fix committed]  http://launchpad.net/bugs/37866
[02:13] <cprov> mpt: yes, as soon as I can get the code reviewed ;)
[02:13] <mpt>  * I'll skip bug 31308, so lifeless doesn't yell at me
[02:13] <Ubugtu> Malone bug 31308 in launchpad-bazaar "Cannot set branch associated to a product series" [Critical,Confirmed]  http://launchpad.net/bugs/31308
[02:13] <kiko> mpt, well.. ok.
[02:13] <malcc> mpt: 35965 is behind process-upload-tidy, which I've nearly finished the review response for, inbetween handover and fixing other critical bugs
[02:14] <mpt> great
[02:14] <mpt> and lastly
[02:14] <mpt>  * Bug #48860 ("Also notified" makes difficult to unsubscribe), Confirmed, Critical, not assigned
[02:14] <mpt> Who should take 48860? bradb?
[02:14] <Ubugtu> Malone bug 48860 in malone ""Also notified" makes difficult to unsubscribe" [Critical,Confirmed]  http://launchpad.net/bugs/48860
[02:14] <kiko> mpt, yes.
[02:14] <bradb> woo
[02:15] <SteveA> mpt: how many other critical bugs do we have?
[02:15] <mpt> 20 in total
[02:15] <SteveA> you could start this section by saying "today, we'll look at the oldest N of M critical bugs"
[02:15] <mpt> ok, will do.
[02:16] <mpt> But for this week, I'm done.
[02:16] <SteveA> all done?
[02:16] <SteveA> great
[02:16] <SteveA> thanks mpt. 
[02:16] <SteveA>  * Production and staging (Stuart)
[02:16] <kiko> bradb, this is /not/ about ressurecting ignore subscriptions! :-P
[02:16] <stub> Nothing thrilling is happening with production at the moment. It is unlikely there will be an update next week as I will be sprinting in London unless there is something urgent and I'm given a window to do the update.
[02:16] <stub> The next update after the sprint I'd like to take the system down for 2.5 hours while I do a complete dump/restore as this is the fastest way for me to rebuild indexes and completely vacuum the tables - 
[02:16] <stub> this should speed things up as the db will be shrunk considerably making everything fit in RAM again.
[02:16] <stub> Staging database is being rebuilt daily, however the code updates are currently only happening when myself or Carlos runs them manually.
[02:16] <stub> This will be the case until RT 603 is dealt with (there is a quick fix on this issue, so this shouldn't be a problem).
[02:16] <kiko> stub, I'm fine with no rollout next week, fwiw
[02:17] <SteveA> stub: in the next full rollout (whenever that is) there will be more vhosting changes/fixes.
[02:17] <SteveA> we'll be changing from blueprint.launchpad.net to features.launchpad.net
[02:17] <stub> cprov mentioned stuff needing to go out - no idea if there are db patches to go with it.
[02:17] <SteveA> as well as enabling features.launchpad.net on production
[02:17] <cprov> stub: no db patches, only code
[02:17] <stub> blueprint.launchpad.net isn't active yet anyway.
[02:18] <SteveA> so we should make sure these are tested on staging well, once the changes land there
[02:18] <mpt> Features?
[02:18] <stub> We still need to turn the Host: headers on - last time we gave it a go it failed horribly.
[02:18] <SteveA> matsubara: that's something for you to look at perhaps
[02:18] <cprov> stub: not sure if we are allowed to do only drescher rollout, though. what do you think ?
[02:18] <stub> cprov: Sure.
[02:18] <malcc> stub: I've hit a testing problem with the bugfix which blocked drescher rollout last week, after the meeting can I grab you for some help? Basically my doctest doesn't work since I moved it and I'm stuck
[02:18] <SteveA> stub: is there a bug to track the problems turning the Host header on?
[02:18] <SteveA> stub: and also, why did it fail on production but not on staging.  that is worrisome
[02:18] <stub> SteveA: I think the RT issue is still open
[02:19] <SteveA> stub: which RT issue?
[02:20] <stub> Can't find it. Might be my imagination. 
[02:20] <SteveA> as this is a launchpad bug primarily, I think we should have a launchpad bug to track this
[02:20] <SteveA> stub: would you dump what you know into a bug please?
[02:20] <stub> SteveA: RT 13138
[02:20] <kiko> SteveA, you're alve
[02:21] <SteveA> aha
[02:21] <SteveA> ok
[02:21] <SteveA> about the 2.5 hour downtime
[02:22] <SteveA> what's the procedure for arranging that?
[02:22] <stub> I need to clear it with mdz basically
[02:23] <stub> Which involves me knowing when it will happen, so I haven't done that yet.
[02:23] <SteveA> I think for such a downtime, an early announcement on one of the canonical lists would be good
[02:23] <SteveA> we haven't had such a downtime for a while
[02:23] <kiko> why is staging down currently, stub?
[02:23] <SteveA> and it's possible that other things are going on that we don't know about
[02:23] <SteveA> that would be badly affected by the downtime
[02:23] <stub> kiko: It is down?
[02:23] <kiko> yes.
[02:24] <SteveA> so, send a message to the warthogs or all hands lists announcing the downtime, and saying you'll be consulting with mdz for distro needs
[02:24] <kiko> can't we get a notification or something when it's down?
[02:24] <SteveA> but for people not on the distro team to tell you if there will be other things to consider
[02:24] <flacoste> flacoste: should we sent an announcement to launchpad-users as well?
[02:24] <SteveA> we should do that once the date is set
[02:25] <stub> SteveA: We have a procedure for this, which I will follow when I know roughly when it will happen.
[02:25] <SteveA> but we should get feedback from certain places in order to set the date
[02:25] <SteveA> stub: yes.
[02:25] <stub> It is on the wiki as a spec
[02:25] <SteveA> stub: my point is that the spec may be out of touch with reality, so a message reminding people of what's going to happen would help
[02:25] <SteveA> then any changes would go into the spec
[02:25] <stub> ok
[02:25] <SteveA> also, that spec might need to be moved to help.launchpad.net
[02:25] <SteveA> thanks for the production status report, stub
[02:26] <SteveA>  * Launchpad 1.0 status reports
[02:26] <SteveA> kiko: I'd like to give this item to you
[02:26] <kiko> well, sure.
[02:26] <danilos> I can comment on Rosetta 1.0 goals and progress, if needed
[02:26] <SteveA> this week can be an introduction
[02:26] <kiko> we'll be doing a weekly catch-up with people on their 1.0 goals and progress
[02:26] <SteveA> to say what we'll do in subsequent weeks
[02:27] <kiko> this is a way of us touching base as a group and seeing who the most doomed engineer of the week is 
[02:27] <danilos> ha (I used the same "goals and progress" phrase as kiko ;)
[02:27] <kiko> danilos, shh people will think we are automatons
[02:27] <danilos> ;)
[02:28] <kiko> SteveA, we /could/ do something like 3 sentences where people pasted in specs and statuses. what do you think?
[02:28] <kiko> OT: danilos, btw, you should subscribe to launchpad-reviews
[02:28] <SteveA> kiko: yep.  let's discuss the format later and try it next week.
[02:28] <SteveA> we'll mail out something early next week
[02:28] <danilos> maybe using things from specs, such as "good progress", "blocked", etc.
[02:28] <kiko> okay. thanks for listening.
[02:28] <SteveA> so people can be prepared
[02:28] <kiko> danilos, I was thinking exactly that
[02:28] <danilos> kiko: sure, thanks for reminding
[02:29] <SteveA> I'm going to move on
[02:29] <SteveA> thanks kiko
[02:29] <SteveA>  * Sysadmin requests
[02:30] <stub> RT 603
[02:30] <SteveA> 4
[02:30] <danilos> #14579 (VoIP), stub to give me details for database access via sodium
[02:30] <SteveA> what's 603 about?
[02:30] <stub> Getting staging auto updates working again.
[02:30] <stub> The quick fix is to mirror rocketfuel-built onto asuka.
[02:31] <stub> danilos: ok. Will do that after the meeting.
[02:31] <SteveA> ok
[02:31] <danilos> stub: thanks
[02:31] <SteveA> 4
[02:31] <SteveA> 3
[02:31] <SteveA> 2
[02:31] <SteveA> 1
[02:31] <SteveA> done
[02:31] <cprov> stub: can we have access to the dogfood postgres logs ? i mean, as local launchpad user.
[02:31] <SteveA>  * Using email in a distributed team (Steve, Kiko)
[02:31] <SteveA> this is just a quick item
[02:31] <kiko> to remind people
[02:32] <SteveA> use email.
[02:32] <SteveA> mail the list in preference to individuals.
[02:32] <stub> cprov: Maybe the admins can do that if you RT. I don't think I can fix that.
[02:32] <cprov> stub: okay, tks
[02:32] <kiko> don't lose days because you were waiting for somebody on IRC
[02:32] <SteveA> always reply to email asking you to do something or about something.  reply promptly, even if the reply is
[02:32] <SteveA> "I'll look at this next week."
[02:32] <kiko> and that somebody is asleep, on holiday, sick
[02:32] <SteveA> so that the sender knows you're aware of it
[02:32] <kiko> send them email, and CC: the list
[02:32] <kiko> that is all.
[02:33] <SteveA> that is indeed.
[02:33] <SteveA>  * Python demo status update (James H)
[02:33] <danilos> thanks guys, always good to get such reminders
[02:33] <SteveA> basically, we have a demo at demo.launchpad.net
[02:33] <SteveA> and kiko and james are corresponding with the python guys
[02:34] <SteveA> and mpt is adding cropped screenshots to the Malone features doc on the wiki
[02:34] <kiko> ah, very nice
[02:34] <SteveA> https://help.launchpad.net/MaloneHighlights
[02:34] <SteveA> which mark wrote last weekend
[02:34] <SteveA> so we can mail the python guys pointing them at the highlights with screenshots tommorrowish
[02:34] <SteveA> who will send that email?
[02:34] <kiko> I will look at a random sample of bugs from the import now that we have a way of comparing with the original bug.
[02:34] <SteveA> mpt should tell the list + that person when the screenshots are done and included
[02:34] <kiko> SteveA, why don't you send that email?
[02:35] <kiko> you have a good standing with the python people
[02:35] <SteveA> I'm not on the lists, and I'm going to be really really busy tomorrow
[02:35] <SteveA> kiko and james have already be corresponding
[02:35] <SteveA> so I want either kiko or james to send this followup
[02:35] <kiko> okay. I am on the lists.. I guess I could. where am I supposed to write? python-dev? infrastructure? CC infrastructure?
[02:35] <SteveA> whereever the discussion has been happening
[02:35] <bradb> infrastructure,
[02:35] <SteveA> certainly the infrastructure guys
[02:36] <SteveA> but the list too, if it is appropriate
[02:36] <SteveA> so, mpt, please tell kiko cc list when it is done
[02:36] <kiko> should I reply to an existing post or start a new thread?
[02:36] <SteveA>  * Tagging Launchpad bugs (bradb)
[02:36] <bradb> We should start tagging our bugs, to make it easier to find, search through, and deal with groups of bugs that interest us.
[02:36] <bradb> I've written a mini-proposal on some standard tags I think we'd all benefit from: https://help.launchpad.net/TaggingLaunchpadBugs. This document also notes the procedure for proposing new tags.
[02:36] <bradb> I'd like to get the team's feedback on using the tags I've proposed.
[02:36] <bradb> (That is all.)
[02:36] <mpt> SteveA, roger that
[02:37] <SteveA> ok
[02:37] <kiko> bradb, SteveA: without linkifying individual tags in the pages.. it's not very convenient to use them.
[02:37] <SteveA> so, everyone look at https://help.launchpad.net/TaggingLaunchpadBugs
[02:37] <matsubara> bradb: I'd propose ui instead of usability (it's much easier to type)
[02:37] <SteveA> let's start with...
[02:37] <SteveA>  * oops
[02:37] <malcc> We're already using a bunch of Soyuz tags, do we need to propose these?
[02:38] <SteveA> matsubara, are you in favour of the tag, plus the meaning brad proposed?
[02:38] <SteveA> malcc: they should be documented on the wiki in a similar way
[02:38] <mpt> Does that mean the oops milestones should be removed?
[02:38] <flacoste> we already have the oops milestone?
[02:38] <matsubara> yes SteveA. but what happens to the oops milestone?
[02:38] <SteveA> mpt: in general no, but yes when we want to use tags instead
[02:38] <bradb> i think we should migrate the data to a keyword, yeah
[02:39] <SteveA> mpt: so, "oops" tracking is a better fit for tags than milestones
[02:39] <mpt> I meant just the oops milestones, not milestones in general
[02:39] <malcc> ActionItem: me, cprov, to document Soyuz bug tags
[02:39] <SteveA> do we have more than the one OOPS milestone?
[02:39] <kiko> matsubara, mpt: i'd get rid of the oops milestone.
[02:39] <mpt> There's one for each product, iirc
[02:40] <SteveA> malcc: please do so on the same page as the one brad's ones are on, so we have them all in one place
[02:40] <matsubara> I'd propose an timeout tag too
[02:40] <malcc> SteveA: Roger
[02:40] <cprov> malcc: draft added in https://launchpad.canonical.com/SoyuzCatchUp
[02:40] <SteveA> ok.
[02:40] <bradb> so, anything other than the oops tag, to start with?
[02:40] <Kinnison> argh, i'm being restbreaked
[02:40] <SteveA> I propose we start with: oops, ui, timeout
[02:40] <SteveA> and then see how that goes
[02:41] <SteveA> a countdown of 5 for extreme dissent:
[02:41] <SteveA> 4
[02:41] <SteveA> 3
[02:41] <SteveA> 2
[02:41] <SteveA> 1
[02:41] <SteveA> ok
[02:41] <danilos> hum, shall we also get project-specific ones later (eg. should we propose them)?
[02:41] <kiko> proposing sounds good
[02:41] <SteveA> mpt and brad: please work together on this
[02:42] <kiko> random strawman idea:
[02:42] <kiko> should we include counts next to the tags when displaying them in the bug page
[02:42] <ddaa> Me adds some project-specific tags he plans to use
[02:42] <SteveA> moving along...
[02:42] <SteveA> kiko: nice idea.  discuss after meeting
[02:42] <mpt> kiko, you mean the Bugs page rather than the bug page, perhaps
[02:42] <SteveA> I'm skipping KBC this week
[02:42] <mpt> ?
[02:42] <SteveA>  * Three sentences
[02:42] <SteveA> BRING THE NOISE
[02:42] <kiko> mpt, no, on the bug page.
[02:42] <mpt> DONE: bugfixing, sprint travel arrangements, issue tracker comparison
[02:42] <mpt> TODO: MaloneHighlights, local bzr repo, more WinIE fixes, other fixes
[02:42] <mpt> BLOCKED: Minor problem with a toolbarless Internet Explorer on Wine
[02:43] <salgado> DONE: Finished take 2 of KarmaContext (top contributors), landed some shipit changes, fixed a few random bugs, added an overall status to mirrors and reviewed some code
[02:43] <salgado> TODO: Land all my pending branches, review more code and fix other random bugs
[02:43] <salgado> BLOCKED: No
[02:43] <ddaa> DONE: finished and rolled out importd/bzr-native
[02:43] <ddaa> TODO: Import python, get remaning bzr-native bits merged, get importd to upload/download source trees on a remote SFTP
[02:43] <ddaa> BLOCKED: no
[02:43] <malcc> DONE: Landed 53437, nearly landed 54039, nearly finished process-upload-tidy review response, handover with Kinnison.
[02:43] <malcc> TODO: Finish current branches, embark upon PPA with archive-rework.
[02:43] <malcc> BLOCKED: By only having one brain.
[02:43] <stub> DONE: Finished and landed pillar names and test suite refactorings.
[02:43] <stub> TODO: Sprint
[02:43] <stub> BLOCKED: RT 603
[02:43] <kiko> DONE: reports, fixes, UI improvements, touching base with the gang
[02:43] <bradb> DONE: Dentist visits. Some holidays. Release management, landed some related API changes.
[02:43] <bradb> TODO: Release management. Finish the work started on guided filebug. Test filebug xmlrpc on production.
[02:43] <bradb> BLOCKED: No.
[02:43] <matsubara> DONE: oops report analysis, fixed small oops bugs.
[02:43] <matsubara> TODO: more oops fixing, sprint, test vhosting stuff on staging as soon as it landsBLOCKED: no
[02:43] <flacoste> DONE Search before creating a ticket, fixed small bugs in the support tracker, work on bug #49760 and bug #52781
[02:43] <flacoste> TODO TicketTrackerWorkflowSpec, pagetests for new +unlinkbug view, add search to +linkbug
[02:43] <flacoste> BLOCKED further TicketTrackerWorkflowSpec work is on hold awaiting kiko's reviews
[02:43] <Ubugtu> Malone bug 49760 in launchpad-support-tracker "UI improvements to remove bug link page: change label, use selection" [Medium,In progress]  http://launchpad.net/bugs/49760
[02:43] <Ubugtu> Malone bug 52781 in launchpad-support-tracker "Link bug should allow searching" [Wishlist,In progress]  http://launchpad.net/bugs/52781
[02:43] <danilos> DONE: work on firefox import, bug 44860 review response
[02:43] <danilos> TODO: put bug 2237 on review, pqm-submit bug 1788, work on bug 30602, finish firefox import, start export, handle rosetta-experts stuff (xaraxl, pluralforms, edgy opening)
[02:43] <danilos> BLOCKED: nope
[02:43] <Ubugtu> Malone bug 44860 in rosetta "Crash when we try to pass a query string to a POFile that doesn't exist yet." [Critical,In progress]  http://launchpad.net/bugs/44860
[02:43] <BjornT> DONE: catch up from vacation. working with james on form stuff.  reviews. bug fixes.
[02:43] <Ubugtu> Malone bug 2237 in rosetta "Preferred languages (and link to change them) twice on translation template page" [Medium,In progress]  http://launchpad.net/bugs/2237
[02:43] <Ubugtu> Malone bug 1788 in rosetta "Saving preferred languages looks like it does nothing" [Medium,In progress]  http://launchpad.net/bugs/1788
[02:43] <Ubugtu> Malone bug 30602 in rosetta "ERROR IN: https://launchpad.net/distros/ubuntu/dapper/+source/vlc/+pots/vlc/tl/+translate" [Medium,Confirmed]  http://launchpad.net/bugs/30602
[02:43] <BjornT> TODO: some more work on forms. Finish the SimpleKeywords implementation. reviews.
[02:43] <BjornT> BLOCKED: no
[02:43] <kiko> TODO: really fix the big ones that I need to do, review flacoste's patch and then his spec and then.. more reviews in the queue?
[02:43] <kiko> BLOCKED: no
[02:43] <cprov> DONE: several critical bug fixes in soyuz (including build-failure-notification)
[02:43] <cprov> TODO: get code reviewed and rollout fixes in drescher
[02:43] <cprov> BLCOKED: none
[02:44] <Kinnison> DONE: Lots of handover to malcc
[02:44] <Kinnison> TODO: queue-uniqueness(?) and queue-prettiness branch(!) and exhaustive archive verification tool (as much as I can in time)
[02:44] <Kinnison> BLOCKED: Nope, thanks to senokot.
[02:44] <SteveA> DONE: sprint, coding, sprint planning, management
[02:44] <SteveA> TODO: sprint, coding, sprint planning, management
[02:44] <SteveA> BLOCKED: no
[02:44] <jamesh> DONE: code reviews / Some more work on Python bug import / branch vocabulary fixes / LaunchpadFormView work with BjornT
[02:44] <jamesh> TODO: code reviews / Launchpad infrastructure sprint in London
[02:44] <jamesh> BLOCKED: no
[02:45] <SteveA> mpt: I'm interested to talk about your blocker later.
[02:45] <SteveA> That's all folks.  Thanks for being here and keeping attentive.
[02:45] <SteveA> MEETING ENDS
[02:45] <SteveA> so, kiko, what do we need to do to make tags more useful/
[02:45] <SteveA> ?
[02:46] <danilos> wow, exactly on time, thanks SteveA :)
[02:46] <kiko> SteveA, well, I sent BjornT a patch that makes them into links
[02:46] <danilos> stub: can I get details for staging db?
[02:46] <bradb> they're linked from +bugs, at least
[02:46] <kiko> SteveA, we could also include counts next to the tags.. though perhaps that will be offset if BjornT finds a way of giving the user a confirmation screen if the tag he is using is new.
[02:46] <danilos> kiko: can we discuss the steps for bug 30602 after lunch?
[02:46] <Ubugtu> Malone bug 30602 in rosetta "ERROR IN: https://launchpad.net/distros/ubuntu/dapper/+source/vlc/+pots/vlc/tl/+translate" [Medium,Confirmed]  http://launchpad.net/bugs/30602
[02:47] <kiko> danilos, whose lunch?
[02:47] <SteveA> malcc, cprov: I want us to consider tags to be "global" to the launchpad project, and not have special soyuz ones
[02:47] <danilos> kiko: my lunch ;)
[02:47] <stub> danilos: I think it is setup, but we lack clients on sodium. So I've just rt'd it.
[02:47] <kiko> ok
[02:47] <SteveA> what I mean is, we can have ones that are useful for soyuz
[02:47] <stub> danilos:  psql -d launchpad_staging -h sodium -U ro
[02:47] <SteveA> but we don't need a special category for them on that page
[02:48] <danilos> stub: ok, so I won't need to know anything else except the database name and host to access it?
[02:48] <SteveA> so, please add the tags you're using to the proposed section of https://help.launchpad.net/TaggingLaunchpadBugs
[02:48] <stub> Ok. I've got to grab dinner before my sister flys out. I'll be back in 1.5 hours if anyone needs me.
[02:49] <cprov> SteveA: yes, I agree, I will propose the soyuz tags as they are and we can discuss them later 
[02:49] <danilos> stub: ah, great, that's what I was wondering, thanks
[02:51] <SteveA> jamesh, BjornT: let's go get some lunch
[02:51] <BjornT> sounds good
[02:55] <SteveA> ddaa: please add your tags in a single table on the proposed tags page
[02:55] <ddaa> SteveA: in my understand that table is for global launchpad bugs
[02:55] <ddaa> s/bugs/tags/
[02:55] <SteveA> as I was just saying to malcc and cprov, I don't want us to have product-specific tags, but to have a collection of tags that are meaningful for the whole project
[02:55] <ddaa> hu?
[02:55] <SteveA> so, if your tags don't make sense in the whole context of launchpad, they need to be changed
[02:55] <SteveA> ddaa: you just updated the wiki page
[02:56] <SteveA> and added a new section for launchpad-bazaar tags
[02:56] <SteveA> I don't want this
[02:56] <ddaa> I have already been using project specific tags, using the fti
[02:56] <SteveA> I want a single section for launchpad tags
[02:56] <ddaa> https://launchpad.net/products/launchpad-bazaar/+bug/49989
[02:56] <Ubugtu> Malone bug 49989 in launchpad-bazaar "branch puller reports failure for new hosted branches" [Low,Confirmed]  
[02:56] <SteveA> so that we get some consistency across launchpad
[02:56] <ddaa> I do not see the point of forbidding the use of projec specific tags
[02:56] <sivang> re
[02:56] <ddaa> but, hey, you're the chef
[02:56] <SteveA> one reason is this
[02:56] <SteveA> you have "importd" as a tag
[02:57] <SteveA> that is not specific enough in the context of launchpad as a project
[02:57] <SteveA> because we also import translations
[02:57] <ddaa> My Change for today was: merge launchpad sub-projects and use tags instead
[02:57] <SteveA> I think you should rename "scanner" to "branch-scanner" or "branchscanner"
[02:57] <ddaa> so we can differentiate "rosetta importd" and "bazaar importd"
[02:57] <malcc> SteveA: One of the things we were hoping, in Soyuz, to use tagging for is effectively, as ddaa said, subproject-type splitting, I can't see how we can make those tags useful generically
[02:58] <SteveA> that way, there's just one table for people to look at to understand what all the tags mean
[02:58] <SteveA> malcc: that's fine.  they just have to be *understandable* without noticing the soyuz context
[02:58] <malcc> SteveA: Ah ok, I get it
[02:58] <SteveA> so, ddaa should rename "scanner" to "branchscanner"
[02:58] <SteveA> because "scanner" makes little sense on its own
[02:58] <ddaa> pain
[02:58] <SteveA> but "branchscanner" makes sense on its own
[02:59] <SteveA> merge it into the other one
[02:59] <SteveA> the tags are all valid
[02:59] <SteveA> they just might need new names
[02:59] <ddaa> I do not want to have to use long-winded tags like that
[02:59] <ddaa> esp since we do not have completion
[02:59] <ddaa> fti does a good enough job for me
[03:00] <SteveA> tags more for readers than for writers
[03:00] <SteveA> so an extra 6 characters will not hurt
[03:00] <SteveA> and will help people who only occassionally have to interact with your parts of launchpad
[03:01] <SteveA> I cannot believe you're complaining about changing "scanner" to "branchscanner"
[03:01] <SteveA> or "bzrscanner"
[03:01] <ddaa> it's about convenience
[03:01] <SteveA> or whatever.
[03:01] <LarstiQ> banner?
[03:01] <SteveA> yours or other peoples' ?
[03:02] <ddaa> SteveA: it's simple, I put that table up because I thought it would be convenient for me to use those tags. Now, make the tags more cumbersome, and it no longer appears more convenient for me to use tags instead of fti as I have been doing up to now.
[03:03] <ddaa> Now, if you decide that those tags are a good idea and that you want me to use them anyway, in their long form, it's your prerogative, but it's not the choice I would make voluntarily _right now_.
[03:06] <LarstiQ> on the subject of tags, I missed the introduction. They seem to be completely freeform, what methods of filtering them are available?
[03:07] <kiko> LarstiQ, it's good you ask! bradb is pointing to me that they are listed on +bugs
[03:08] <kiko> LarstiQ, but I find that obscure and hard to relate to
[03:08] <kiko> so I wrote a patch which linkifies them in the bug page itself.
[03:08] <LarstiQ> kiko: this is per product/project? How about looking at a wider scope?
[03:15] <sivang> kiko: yo
[03:15] <kiko> oy
[03:15] <kiko> LarstiQ, you can query for them in a specific context.
[03:51] <mdz> kiko: what's this about an outage?
[03:52] <kiko> mdz, we need to do some database maintenence, stub wants to check with you for an appropriate date.
[03:52] <kiko> bradb, ping?
[03:52] <mdz> kiko: also, was the initial list of tags seeded from somewhere?  it's huge and contains a lot of noise
[03:52] <bradb> kiko: pong
[03:53] <mdz> like package names and 'ubuntu' and release codenames
[03:53] <kiko> mdz, nope. it's been added randomly. I know there's a problem with that -- BjornT and I have a plan on improving that (getting confirmation when you are adding a tag that hasn't been used before)
[03:53] <mdz> 'error'
[03:53] <kiko> mdz, but the idea /was/ to have lightweight tags -- which were easy to define and abandon.
[03:54] <kiko> mdz, do you feel there should be more structured policy there? perhaps prefix your tags with something that implies official?
[03:54] <kiko> bradb, I need a phrase which doesn't contain the word "task" that says "There is a fix for this in one of the other tasks on this bug".
[03:55] <kiko> bradb, you are my task-avoidance expert!
[03:55] <bradb> kiko: "Fix exists"
[03:55] <kiko> bradb, that's ambiguous with "Patch attached"
[03:55] <kiko> which I'm also adding, fwiw
[03:56] <bradb> fix exists != patch attached, as best i can tell. patch is more like "fix proposed"
[03:56] <bradb> alternatively "fixed in $there"
[03:57] <kiko> bradb, that's implying the user will think like you do. which is often not the case. :)
[03:57] <kiko> fixed in there is an interesting example
[03:57] <kiko> thanks!
[03:57] <bradb> np
[04:03] <kiko> I wish mpt were here
[04:03] <kiko> I need 3 icons.
[04:17] <sivang> matsubara: ping
[04:17] <matsubara> hello sivang 
[04:18] <sivang> matsubara: hey there dude, what's up?
[04:20] <matsubara> sivang: freezing!
[04:36] <sivang> matsubara: I thought you were in brazil no?
[04:38] <matsubara> sivang: yes, I am.
[04:46] <stub> kiko: Do you think I should proceed with running the queries in Bug 54710 on production? Or where the results not what we wanted?
[04:46] <kiko> stub, I will email you with an analysis. I needed staging up to be able to confirm.
[04:46] <stub> kiko: Staging should be up now, but the db will have been reset. I'll rerun the queries.
[04:46] <kiko> stub, ah, right. thanks.
[04:47] <stub> kiko: I've switched off staging updates entirely now - the db upgrade would kill the launchpad instance, and then the code update would fail and the server would not be restarted.
[04:49] <stub> kiko: Bugs are updated. Nuking unwanted sourcepackagename's now (will take a few mins)
[04:49] <kiko> thanks
[04:51] <stub> danilos: You should have access to the staging database now - works for me from sodium anyway.
[04:52] <sivang> matsubara: regarding malone #3186 , are you onto it already or can I help it? :)
[04:52] <Ubugtu> Malone bug 3186 in blueprint "New spec form has undescribed no-capitals constraint" [Medium,Confirmed]  http://launchpad.net/bugs/3186
[04:59] <matsubara> sivang: I won't work on it in the near future
[05:03] <sivang> matsubara: okayy
[05:16] <kiko> for the record
[05:16] <kiko> before somebody asks me
[05:16] <kiko> I HATE ZCML
[05:16] <sivang> hehe
[05:17] <SteveA> kiko: we're removing our use of it by degrees
[05:17] <kiko> SteveA, I want to give you an additional 179 then!
[05:19] <malcc> Anyone got a minute to help with a testing problem?
[05:19] <malcc> The test here: https://sodium.ubuntu.com/~jamesh/pending-reviews/malcolmcleaton/launchpad/bug-54039/full-diff ...
[05:19] <kiko> man our edit icon is ugly
[05:19] <malcc> I've tried all sorts of layers, and setting up Librarian myself or not, and I've collected a fine array of different error messages, but the test hasn't worked since it was in launchpad/doc
[05:19] <malcc> Hopefully I've made a really obvious mistake somebody can spot for me
[05:20] <danilos> stub: are you sure the proper -h is sodium? (that sounds a bit strange to me, and I get "connection refused")
[05:20] <kiko> SteveA, can you assist malcc?
[05:21] <SteveA> not right now
[05:22] <stub> danilos: Erm... -h asuka. Sorry :)
[05:22] <kiko> salgado, could you help malcc?
[05:23] <stub> I probably need a help - I have yet to document and notify the new test env ;)
[05:24] <salgado> kiko, I guess I won't be of much help.  matsubara had a similar problem yesterday when he moved one of his doctests outside the canonical/launchpad/doc/ directory
[05:24] <salgado> (similar in the sense that it stopped working)
[05:24] <SteveA> don't get stuck on this
[05:24] <stub> malcc: I'd recommend LaunchpadZopelessLayer for that test. No need to setup/teardown the librarian.
[05:24] <SteveA> file a bug
[05:24] <kiko> salgado, even saying that is help.
[05:24] <kiko> yeah
[05:24] <SteveA> and leave it in the doc directory
[05:24] <kiko> malcc, don't get stuck on this
[05:25] <SteveA> we'll refactor the tests that are in there later
[05:25] <SteveA> calling it bug-whatever-whatever.txt is enough to distinguish it
[05:25] <SteveA> oh, please use '-' not '_' in the name
[05:25] <malcc> I'll try LaunchpadZopelessLayer, change the name to -, and then move it back to doc and file a bug if nothing else works
[05:25] <malcc> Thanks everyone
[05:26] <kiko> yayzers
[05:26] <malcc> s/"to -"/"to use -"/
[05:27] <stub> malcc: Paste me the output of ./test.py -vv --test=bug-whatever-whatever.txt if it fails - I can probably tell you what needs to be done from that.
[05:27] <SteveA> i don't think it is worth having special test setup for this test
[05:28] <SteveA> when the main thing about it is for it to be distinguished from docs
[05:28] <SteveA> if we're going to do this we should have a launchpad/regression directory
[05:28] <SteveA> and do the same as for laucnhpad/docs in there
[05:28] <SteveA> rather than do this one test at a time
[05:28] <SteveA> otherwise, we'll end up with slightly different doctest running code spread around the place
[05:28] <stub> One stub can run multiple .txt text files
[05:29] <SteveA> stub: you're volunteered
[05:29] <kiko> calma SteveA 
[05:29] <stub> For what? I don't want all the tests stuck in one directory. I want them near the code they are testing.
[05:29] <SteveA> stub is the one true stub
[05:29] <stub> Garh!
[05:30] <kiko> stub, I agree with you with my little voice
[05:30] <SteveA> I think I agree too, but...
[05:30] <SteveA> I think it is worse to have a little bit of one layout and a lot of another
[05:30] <SteveA> if we're going to change, we should change properly
[05:30] <SteveA> not just change for this test because we felt like it for this test
[05:31] <stub> ok.
[05:31] <SteveA> the current sourcecode layout is there because the rules for where to put things were too confusing
[05:31] <SteveA> it is a simple rule to say "regression doctests go in launchpad/regression"
[05:31] <SteveA> that keeps the launchpad/doc area tidy, with just real docs
[05:31] <SteveA> a further change would be to revisit the sourcecode layout rules
[05:33] <sivang> kiko: re malone #3186 , matsubara noted you may be interested in changing the validation rules, so before going to adding the instruction there I'd like to consult with you.
[05:33] <Ubugtu> Malone bug 3186 in blueprint "New spec form has undescribed no-capitals constraint" [Medium,Confirmed]  http://launchpad.net/bugs/3186
[05:34] <sivang> kiko: how would you like this bug to be solved?
[05:37] <salgado> so, changing the layer made matsubara's test to work again
[05:37] <salgado> did it work for you, malcc?
[05:37] <malcc> It might have done. I have a different error now but my script is getting 500's from the librarian, I'm just trying a couple more things
[05:38] <salgado> nevermind, he moved it back to launchpad/doc
[05:38] <SteveA> malcc: so, I think the easiest thing is to update the module that runs tests in launchpad/doc
[05:38] <SteveA> so that it also runs tests in launchpad/regression
[05:38] <SteveA> and then move your doctest there
[05:39] <malcc> SteveA: Ok, I'll try that next
[05:39] <SteveA> that also makes it a breeze for ractoring out regression tests from other doctests in launchpad/doc
[05:39] <SteveA> and fits in well with our source code layout
[05:39] <sivang> anyway, gotta go now, be back in 1 hour or less
[05:45] <flacoste> talking about tests: wouldn't xxx-views.txt be a better name than xxx-pages.txt for view tests?
[05:47] <SteveA> I think actually...
[05:47] <SteveA> that we should have a directory for view tests
[05:47] <SteveA> they're not generally documentation either, although sometimes they are
[05:47] <SteveA> I want to eventually move to a system where we can combine doctests and unittest-style tests in a single place, getting the benefits of both
[05:48] <kiko> SteveA, agreed entirely on that point.
[05:48] <SteveA> it's on my list for next week
[05:48] <kiko> but I think that "single place" should be close to the objects they test. :-/
[05:49] <kiko> so you could have database/doc/
[05:49] <kiko> browser/doc/
[05:49] <kiko> etc
[05:49] <flacoste> SteveA: also, think about the reusable interface implementation doc test
[05:49] <SteveA> that idea has some merit
[05:49] <kiko> of course, you could really split things differently.. but..
[05:49] <SteveA> here's how I want to manage these changes
[05:49] <kiko> flacoste, interfaces/doc
[05:49] <kiko> la la la
[05:49] <SteveA>  - all implementation to land in RF uses the current organisational rules
[05:50] <SteveA>  - changes to sourcecode layout need a proposal of what the layout would be, and a description of the improvements and any disadvantages to that change
[05:50] <flacoste> kiko: yes, but you need a way to setup the test for multiple target, you'll find an example in the branch that you are currently reviewing
[05:50] <flacoste> kiko: i put it in interfaces/ftest, but I agree that interfaces/doc would be better
[05:50] <kiko> yeah
[05:51] <SteveA> I'm concerned that people are looking for ways to change things as they go along
[05:51] <SteveA> and that's not a good thing, as it will lead to disorganisation
[05:51] <SteveA> and make it harder to choose a good approach and fully go for it down the line
[05:52] <SteveA> I welcome the discussion on the mailing list about more use of adapters
[05:52] <SteveA> and I'd welcome some discussion of different source code layouts
[05:52] <SteveA> but (to say again) I don't want to see these things land in RF until we've thought them through and agreed on a consistent approach.
[05:52] <flacoste> SteveA: but there is also the 'Waiting for the Big Change' syndrome
[05:53] <SteveA> what is that?
[05:54] <LarstiQ> aaron hanging back because he thought bzr 0.9 would be released soon, instead of taking a couple of weeks
[05:54] <SteveA> I'm arguing for the opposite of that
[05:54] <SteveA> that we make no changes in what we're doing
[05:54] <SteveA> and instead discuss what we'd like to do
[05:54] <flacoste> well, it's the syndrome that we don't change anything now because we want to find a definitive way to do it and since it involves 'Big Changes' that gets put off until later
[05:56] <SteveA> I don't think I've talked about "Big Changes".  What I am talking about is considering carefully before we change our coding policies.  And not making changes against those policies in the mainline.
[05:57] <flacoste> SteveA: I understand and I agree that discussing the thing before hand is a good thing to do
[05:57] <SteveA> we don't need to put off making such changes for some perfect solution.
[05:57] <SteveA> we just need to be able to see that a proposed change is
[05:57] <SteveA>  - better than what we have
[05:58] <SteveA>  - better enough to be worth the effort of changing
[05:58] <SteveA>  - possible to change to in a way that leaves things consistent and easy to comprehend
[05:58] <SteveA> So, for example, if we have a proposal for where tests go in the source tree
[05:58] <SteveA> and it meets these criteria
[05:58] <SteveA> then we don't need to wait for something in particular, other than someone's time, to do it
[05:59] <kiko> SteveA, as long as the changes are not put off forever (think CrowdControl) I think everybody will be happy with that policy
[05:59] <kiko> the problem which arises is when the changes take forever and people start "getting ideas".
[06:00] <SteveA> CrowdControl fits into the "other than someone's time" category
[06:00] <kiko> it's a bit like feeding gladiators to the lions
[06:00] <kiko> if you get my meaning
[06:00] <SteveA> you mean christians, I think
[06:00] <malcc> kiko: Can I be fed to the lions please? :)
[06:00] <SteveA>  ..., christian
[06:00] <kiko> malcc, note that I did /not/ say DDR freaks
[06:01] <kiko> and SteveA, well, I didn't want to mix politics with religion
[06:01] <SteveA> I think lions are non-partisan
[06:02] <stub> The ftests directory is a legacy from the old way functional tests were detected. We can drop it now and stick them all in tests if we want.
[06:02] <kiko> in the 21st century there are few lions left, and none of them are non-partisan.
[06:02] <kiko> anyway, mwaaa
[06:02] <kiko> sivang, do the fix which seems to be the easiest for you
[06:03] <kiko> sivang, probably just making it clear that they need to be all-lowers, and a decent error message, would do the trick
[06:04] <SteveA> bradb: note that I added example URLs to the table of proposed tags.
[06:04] <SteveA> well, I added one example URL
[06:04] <SteveA> I think a proposal for a bug tag should have an example of a bug that would use that tag
[06:04] <bradb> SteveA: ah, cool
[06:05] <bradb> you might want to use the short url form
[06:05] <bradb> .../bugs/...
[06:09] <LarstiQ> MaloneHighlights is a nice read btw.
[06:41] <ddaa> crap, how do I fix the "ProgrammingError: ERROR:  function ensure_session_client_id("unknown") does not exist" thing?
[06:41] <salgado> dropdb session && make schema?
[06:42] <salgado> matsubara says it's session_dev
[06:42] <ddaa> % dropdb session
[06:42] <ddaa> dropdb: database removal failed: ERROR:  database "session" does not exist
[06:42] <stub> dropdb session_dev
[06:42] <ddaa> looks better indeed
[06:43] <ddaa> thanks
[06:50] <elmo> stub: ?
[06:50] <stub> elmo: yo
[06:50] <elmo> oh, never mind you're logged in
[06:50] <elmo> fascist kernel is lieing to me
[06:50] <elmo> I was checking you aware of gandwana, but presumably you are
[06:50] <stub> yup. Just cherry picking.
[07:27] <kiko-fud> the potato is cooking
[07:48] <kiko> hey danilos 
[07:48] <kiko> no chance for that discussion today I don't think
[07:55] <danilos> kiko: hum, ok
[07:55] <danilos> kiko: I'll go through it tommorow morning, and when you show up, I'll hopefuly be ready with some questions ;)
[07:55] <danilos> kiko: how does that sound?
[07:59] <kiko> danilos, that sounds better. I'm at the moment frustrated by the fact that KarmaContext doesn't really help us solve +translations as much as I hoped it would
[08:00] <kiko> one problem I am having is that karmacontext stores product, distribution and packagename, and unfortunately potemplates are associated with series and releases
[08:01] <kiko> this is frustrating to say the least.
[08:01] <danilos> kiko: ah, that annoying bug... hum, if KarmaContext would help, then a 'limit' on queries should do, no?
[08:01] <kiko> well
[08:01] <danilos> or am I totally off here? :)
[08:01] <kiko> the question is
[08:01] <kiko> how do I restrict the query on pofile based on product and distribution... hmmm.
[08:02] <kiko> I have an idea.
[08:02] <danilos> ideas are great, I have them sometimes as well ;)
[08:03] <danilos> anyone going to prettify rosetta.svg (diagram of relations) so I can print it at a0 and put it on a wall in front of my desk? :)
[08:04] <kiko> danilos, stub's the person to nag for that
[08:10] <danilos> oh, stub, you're good at artwork as well? I desire a poster version of rosetta.svg, with pretty icons and all (brown-tango-style will do) :P
[08:11] <kiko> heh
[08:14] <kiko> thanks BjornT!
[08:17] <bluefoxicy> OK so I'm trying to figure out wtf is going on with the bug count and launchpad is not making this easy
[08:18] <bluefoxicy> Can someone add some statistical stuff to track the number of bugs submitted per month; number of duplicates; rate the bugs are triaged and closed; etc?  I'm thinking it might be useful
[08:18] <bluefoxicy> Although aside from saying, "There's too much crap and we can't keep up," I can't see how ;p
[08:18] <kiko> bluefoxicy, well, the current system we have for this kinda sucks
[08:19] <kiko> bluefoxicy, we have graphing software but it runs behind an HTTP AUTH 
[08:19] <bluefoxicy> kiko:  nods.  /me is trying to find a way to file launchpad bug... ah o.o
[08:19] <bluefoxicy> kiko:  so someone's working on that already?
[08:21] <kiko> bluefoxicy, well, not on a generic system, no -- that's considerable effort. but if you just want a graph with counts, we can have one produced, and then somebody would need to grab that graph and put it in a public location
[08:21] <kiko> bluefoxicy, why don't you talk to sfllaw to see if he's that person?
[08:22] <bluefoxicy> kiko:  Mm.  I'll see about that.  Thanks.
[08:22] <kiko> bluefoxicy, enjoy. fwiw the database captures pretty much what you need to be able to graph there already...
[08:22] <bluefoxicy> Yeah, the question is do I have an easy way to grab the numbers from the database
[08:23] <kiko> bluefoxicy, as I said, if the graph is what you want, then it's easy to generate a page with those graphs. and if it's just counts, then you'd need to be specific as to what counts you want
[08:24] <kiko> yawn, man, am I sleepy!
[08:25] <bluefoxicy> kiko:  trying to get per-month counts of all the launchpad bugs, i.e. 300 submitted July 2004, 320 August 2004, 290 submitted september 2004...
[08:25] <bluefoxicy> kiko:  I'll ask sfllaw when he's around.
[08:25] <kiko> bluefoxicy, you mean Ubuntu bugs?
[08:25] <bluefoxicy> yeah, ubuntu bugs, sorry :)
[08:26] <kiko> bluefoxicy, grouped by month?
[08:26] <kiko> or by day?
[08:26] <bluefoxicy> kiko:  month
[08:27] <sivang> kiko: okay, that sounds good. I'm not afraid of attempting harder stuff though :)
[08:27] <bluefoxicy> aye sivang-- Danilo is missing!
[08:27] <bluefoxicy> </obscure nintendo joke>
[08:28] <danilo-missing> ;)
[08:28] <danilo-missing> see ya guys later tonight or tommorow :)
[08:28] <kiko> bluefoxicy, hmmmph. well, if you told me /exactly/ what you want (and it wasn't too much work :) I could be convinced to run some queries for you and give you results. :)
[08:28] <sivang> later danilo-missing 
[08:29] <bluefoxicy> kiko:  Exactly what I want?  The number of new Ubuntu bugs that were submitted for each individual month to Launchpad starting as far back as possible ;)  (or total Ubuntu bug counts per month, which I can just measure the differences between)
[09:26] <bradb> BjornT: ping?
[09:27] <kiko> @#!!$
[09:27] <kiko> bluefoxicy, the former is easier.
[09:30] <bluefoxicy> kiko:  ah, I would have figured the latter would be easier.  Either way; the data is intimately related, you can derive one from the other easily
[09:40] <salgado> hey kiko, how does that shipit patch look now?
[09:50] <kiko> salgado, I think it looks better. do you want a closer look?
[09:51] <salgado> if you give me r=kiko, no. ;)
[09:51] <lucasvo> can one subscribe to a branch as a group?
[10:06] <kiko> lucasvo, mmmm. can you even subscribe to branches today
[10:10] <lucasvo> kiko: but as a group?
[10:10] <kiko> lucasvo, can you subscribe to branches today?
[10:10] <lucasvo> yes
[10:11] <lucasvo> https://launchpad.net/people/harmony-dev/+subscribedbranches
[10:25] <^^EcLipSe^^> hi
[10:25] <kiko> lucasvo, you probably can't subscribe a team, but it should be possible -- it's a simple UI issue. can you file a bug?
[10:26] <lucasvo> ok
[10:26] <kiko> it's really just a UI matter.. interesting even.
[10:27] <lucasvo> why should one be able to subscribe to a branch? what happens then? a notification on every commit?
[10:27] <^^EcLipSe^^> May i ask u a question?
[10:27] <^^EcLipSe^^> Can anyone help me about wireless card driver
[10:27] <lucasvo> kiko: ok I'll file one
[10:27] <^^EcLipSe^^> ??
[10:28] <lucasvo> ^^EcLipSe^^: you are in the wrong channel
[10:28] <^^EcLipSe^^> so where must i have to join?
[10:28] <lucasvo> ^^EcLipSe^^: are you running ubuntu? if so, join the channel #ubuntu
[10:29] <^^EcLipSe^^> i am running suse for now
[10:29] <^^EcLipSe^^> but i order ubundu cds
[10:29] <lucasvo> ^^EcLipSe^^: in that case you will have to go to a suse channel. try #suse
[10:29] <^^EcLipSe^^> ok thanks.
[10:30] <^^EcLipSe^^> care u
[10:32] <lucasvo> kiko: bug 55096
[10:32] <Ubugtu> Malone bug 55096 in launchpad "Groups can't subscribe to a branch even though there is an option to view subscribed branches." [Untriaged,Unconfirmed]  http://launchpad.net/bugs/55096
[10:32] <kiko> thanks lucasvo 
[10:32] <kiko> matsubara, can you keep an eye on that bug, possibly trying to get somebody to fix it this week?
[10:33] <matsubara> kiko: aye
[10:37] <kiko> matsubara, it's basically doing the same as we do for bugs -- subscribe someone else. alternatively, the UI could look like the UI we have for package subscriptions -- subscribe a team you are a member of.
[12:01] <kiko> hey 
[12:01] <kiko> does anyone here have write access to staging?
[12:05] <kiko> oh, I do.