=== mpt [n=mpt@203-167-187-121.dsl.clear.net.nz] has joined #launchpad [12:59] Gooooooooooooooood morning Launchpadders! === boim_ [n=aaron@boim.com] has joined #launchpad === mpt_ [n=mpt@203-167-187-118.dsl.clear.net.nz] has joined #launchpad === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #launchpad === xenru [n=Miranda@85.192.12.26] has joined #launchpad === oohlaf [i=olaf@deschacht.student.utwente.nl] has joined #launchpad === fasdfasdf [n=mc@62.218.230.197] has joined #launchpad [01:58] how to get karma with support? [02:00] i made comments but did not get karma,what does to have happen so that i get karma? [02:18] "This Source has been certified and is now unmodifiable." [02:18] hehe, ehm, how can I change the CVS repo url for https://launchpad.net/products/yate/devel/+source [02:19] upstream changed hosts [02:53] oohlaf: email launchpad-users [03:03] jamesh: oki, do I need to be subscribed, or is it open? [03:03] wiki:MailingLists, which wiki? wiki.ubuntu.com? [03:03] oohlaf: you need to be subscribed. It is low volume [03:03] https://lists.ubuntu.com/mailman/listinfo/launchpad-users [03:32] hmm, that's weird, both yate.null.ro and voip.null.ro point to the same ip [03:33] yet, if I access the cvs repo at voip the last update is a few months ago [03:33] if I use yate.null.ro it is recent [03:34] I don't think CVS had support for name based vhosts [03:41] lifeless: ping? === quail [n=quail@unaffiliated/quaillinux/x-000001] has joined #launchpad [04:01] New bug: #59280 in soyuz "queue tool does not display target pocket" [Untriaged,Unconfirmed] http://launchpad.net/bugs/59280 [04:01] New bug: #59281 in soyuz "queue tool can't filter on source package" [Untriaged,Unconfirmed] http://launchpad.net/bugs/59281 === Keybuk [n=scott@quest.netsplit.com] has joined #launchpad [04:31] jamesh: pong [04:33] lifeless: I've been working on the product series branch stuff, and there was a question that came up with ddaa's mini-review. [04:34] shoot [04:34] lifeless: in my branch, I have series.import_branch being the attribute that importd uses for all its stuff and series.user_branch being setable by the user. The series branch is considered to be user_branch if set, falling back to import_branch [04:36] ddaa mentioned wanting to make sure the series branch is unique, and it isn't trivial to do multi-field unique constraints like this (i.e. saying that user_branch is different to all import_branch values) [04:36] why should it be unique ? [04:36] and I was wondering if things might be simpler if series.user_branch _is_ the product series branch [04:37] and have importd's branch creation look like this: [04:37] (1) create branch and set series.import_branch to it [04:37] (2) if series.user_branch is NULL, assign this branch to that attribute too [04:38] I'm not sure about the uniqueness constraint. He brought it up because the existing field is set to be unique [04:38] ok [04:38] its important that importd only have one reference to each branch [04:38] and its separately important than users not be able to commit to importd branches [04:39] I mentioned that in my reply -- I can see the problems importd would face if that constraint broke [04:39] but I dont think its important that a users branch not be mentioned by two series [04:39] Okay. [04:39] its not very useful, but it may be frustrating to have an arbitrary 'you must fix this somewhere else in the system' error [04:40] what do you think about getting importd to set user_branch if it is NULL? [04:40] particularly if its not /easy/ to get to the other series that happens to be referencing the branch you are trying to set [04:40] coming to that [04:41] so I think its much nicer for users to let them do what they want here - but if we choose to require uniqueness on the series branch, we should make it easy - as a priority IMO - to get to the other branch to change it. A direct link in the error for instance. [04:41] as for implementing uniqueness by having importd assign to user_branch - sure. But rather than checking for NULL, make it not NULL. [04:41] (I've done this in my branch, btw -- the error includes a link to the other series) [04:41] jamesh: nice [04:42] so make it not NULL, that way we'll never have a bug where its not set and we dont fall back for some reason [04:42] make what not null? [04:43] there will be series without Bazaar branches, so user_branch can't be a NOT NULL column [04:43] mmm [04:43] I see a potential for bugs: [04:44] importd_branch is set [04:44] I was also thinking that getting importd to set user_branch would simplify the UI a bit [04:44] series_branch is not set [04:44] but we dont fallback [04:44] so it thinks there is no series branch, but there should be [04:45] thats my only concern [04:45] so that if the user sets up CVS import details and a branch gets created, they'll see that branch in the product series edit form [04:45] at the moment they'd see a blank field [04:46] let me put it another way [04:46] we're saying that there should be an invariant : if there is an importd branch, there must always be a series branch [04:46] the series branch -may- be NULL IFF the importd branch is NULL [04:47] perhaps a constraint on the record, to preserve that invariant is all thats needed to trap bugs [04:47] grabbing food === quail [n=quail@unaffiliated/quaillinux/x-000001] has joined #launchpad [05:31] fasdfasdf, you should be getting karma from helping with support, but that might not start happening for another week or two [05:35] New bug: #59291 in soyuz "queue tool seems confused about NEWness" [Untriaged,Unconfirmed] http://launchpad.net/bugs/59291 [05:40] New bug: #59292 in soyuz "Confusion between +packages and +distributions pages" [Untriaged,Unconfirmed] http://launchpad.net/bugs/59292 [05:54] lifeless: so, I guess removing the uniqueness constraint for series.user_branch would solve most of these issues [05:55] lifeless: also, have you had a chance to look at my product-release-finder branch? [05:55] jamesh: oh, no. I'll do so tonight I think [05:56] lifeless: I put up a second product-release-finder branch (jamesh/launchpad/bug-58847) that includes a merge of the first. It might be easier to just review that. [05:57] (it includes the fix for the UnicodeError we ran into most recently) [05:57] sweet [05:57] shall do [05:58] once that's in, hopefully we'll get a full successful run [06:11] whats the review url? [06:11] (i'm in deep hack mode) [06:11] https://devpad.canonical.com/~jamesh/pending-reviews/jamesh/launchpad/bug-58847/full-diff [06:14] whats the vocab for ? [06:18] I added the dbschema vocab in the previous branch, but forgot to include the registration for it. I guess it'd be worth adding a verifyObject() test to make sure the file info object is being created properly [06:34] ;) [06:34] +1 with that [06:38] thanks. === stub [n=stub@ppp-58.8.5.212.revip2.asianet.co.th] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === glatzor [n=sebi@ppp-82-135-3-178.dynamic.mnet-online.de] has joined #launchpad === dsas [n=dean@host86-129-17-245.range86-129.btcentralplus.com] has joined #launchpad === quail [n=quail@unaffiliated/quaillinux/x-000001] has joined #launchpad === Fujitsu [n=Fujitsu@c58-107-62-26.eburwd7.vic.optusnet.com.au] has joined #launchpad [08:04] morning [08:08] Afternoon, SteveA. [08:10] New bug: #59301 in blueprint "Don't give me a vague "URL is registered by another specification" error" [Untriaged,Unconfirmed] http://launchpad.net/bugs/59301 [08:12] hi Fujitsu. morning! [08:12] Not in Austuralia! [08:13] SteveA: is there a spec for "every false url is a search"? === ryanakca [n=ryan@d226-26-139.home.cgocable.net] has joined #launchpad [08:15] Burgundavia: I dont think so [08:15] Burgundavia: if you write one, please consider http correctness as part of it [08:16] http correctness? [08:16] it should be a 404 [08:16] unlike what moin does [08:16] right, I love what moin does [08:16] 404 are very very human unfriendly [08:16] um [08:16] no [08:16] it *should* be a 404 [08:16] a 404 page can show search results [08:17] moin returns a 200 for a page that doesn't exist [08:17] ah [08:17] meaning that your browser remembers it in the history [08:17] ah [08:17] and caches cache it [08:17] etc. [08:17] while internet explorer often hides 404 pages, it will display them if they are big enough [08:17] bit of a weird behaviour [08:17] jamesh: good point. [08:17] ok, we are talking at different levels. I am talking about what the user sees [08:17] jamesh: there are similar heuristics in parts of outlook, I've found. [08:18] jamesh: MS seem to have a habit of using flakey heuristics. [08:18] Burgundavia: so am I [08:18] Burgundavia: they see whatever the web server sends, usually [08:18] Burgundavia: if the user sees lots of pages that don't exist in their history, or out of date searches because they're cached [08:18] then that's a problem [08:19] ok [08:19] I like the sound of microsummaries in Firefox 2 [08:19] there maybe a a bug on this, but not a spec yet [08:19] jamesh: theres a documented trigger for IO [08:19] IE I mean [08:19] its in the techbase [08:19] anyway, it would be nice if LP was smart when users are dumb [08:20] if we put the right file on our server, you'd be able to bookmark a bug on launchpad, and the bookmark title gets updated when people edit the bugs title [08:20] Burgundavia: If you write a spec for this, I will review it, and get it prioritized on the path to implementation [08:20] SteveA: will do [08:20] jamesh: nice [08:20] SteveA: http://wiki.mozilla.org/Microsummaries [08:20] jamesh: do you know if FF2 will be in edgy? [08:21] SteveA, the beta is. [08:21] SteveA: if Edgy really is 6.10, I doubt it [08:21] b1 is already in edgy [08:21] great. I'll install edgy soon, and try it out [08:21] Burgundavia, isn't it b2? [08:21] Hm. [08:21] You're right, it is only b1. [08:21] Burgundavia: as default, or as an extra package? [08:21] b2 is out but not yet packaged [08:21] default [08:22] it breaks ephy is horrible horrible ways [08:22] lifeless: seems the condition is that the 404 page be larger than 512 bytes [08:22] jamesh: why do they need xslt for microsummaries? [08:23] jamesh: seems overdesigned to me [08:23] SteveA: it is designed to be able to extract a title from the page [08:23] SteveA: and to allow writing microsummary generators for other people's websites [08:23] jamesh: can you ignore the xslt part, and just give them the summary? [08:24] SteveA: no idea. The XSLT could be a simple though [08:24] jamesh: I dont recall precisely, but it is well documented by MS. === mpt [n=mpt@203-167-187-118.dsl.clear.net.nz] has joined #launchpad === BjornT [n=bjorn@clt-84-32-240-183.dtiltas.lt] has joined #launchpad [08:26] jamesh: for launchpad, it would obviously be much much cheaper to render a u-summary than to render the whole page [08:26] hi SteveA [08:26] SteveA: yeah. It isn't clear the spec allows you to direct them to a different URL to retrieve the summary [08:28] jamesh: I can see why they've done it this way -- to make it easy for people who just have file-upload ability to sites to write such summaries, and to allow third parties to write summaries. but... [08:29] I think that should be a fall-back to having a in the document, to a page that has the microsummary [08:29] or having FF request the microsummary with a different mime type [08:30] their spec doesn't give any indication about where to send comments [08:30] I was just looking for such a link [08:30] the only one I see is [edit] ;-) [08:30] myk@mozilla.org might be appropriate === carlos [n=carlos@203.Red-81-35-100.dynamicIP.rima-tde.net] has joined #launchpad [08:31] the links to the examples are on his people.mozilla.com page, and has his email at the bottom [08:31] http://people.mozilla.com/~myk/microsummaries/generators/ [08:32] morning [08:33] jamesh: do you know "myk" ? [08:33] I know his/her name is Myk Melez [08:34] I'm concerned that this feature is like an RSS reader... [08:34] except that it's not reading RSS === ryanakca [n=ryan@d226-26-139.home.cgocable.net] has joined #launchpad [08:34] the web server is given no opportunity to just return the minimum necessary [08:34] so it may encourage webservers to add "number of requests per minute" limitations to all pages [08:35] where such things were previously common just for dynamically generated RSS [08:36] http://www.melez.com/mykzilla/ [08:37] It'd also be nice to be able to include multiple microsummary generators in a single file [08:37] but that doesn't seem possible [08:40] jamesh: would you be interested in blogging about microsummaries? [08:40] sure. [08:40] maybe that's a good way to give public feedback [08:42] personally, I think it's a cool idea, but I'm concerned about the "encouraging a lot of full page renders on a web app" aspect. For example, on launchpad, serving up a simple xml view of the data would make the xsl-t more reliable. [08:42] and we could make it not a resource concern [08:45] SteveA, voice call? [08:46] mpt: sure, but in 15 mins? [08:46] ok [08:47] I'll see if I can fix another bug in 15 minutes ... [08:48] In the meantime you might want to pull mpt/launchpad/2006-08-ui to see progress [09:00] mpt: i'll be ready in a few minutes. ekiga or skype? [09:02] I haven't had a successful call with Ekiga yet, so it depends how much troubleshooting time you have :-) [09:02] I had a good ekiga call with mpool [09:03] so, let's give it a go, and if not, use skype [09:03] ok [09:03] ill wait until I've merged your branch [09:06] it is half way through merge phase zero [09:08] and now it is done [09:08] that phase zero... it's the big one [09:08] Big fat zeroes [09:10] mpt: I'm running ekiga now [09:11] let me know when you are, and I will call you [09:11] I am [09:12] funny... my headset connects and reconnects for each ring [09:12] I clicked "Accept" and immediately got "Remote user has stopped calling" [09:12] so it goes beep-ring-beep (pause) beep-ring-beep (pause) [09:13] i'll call again [09:13] ok, let's try skype [09:13] ok === Spads [n=crack@host-87-74-19-213.bulldogdsl.com] has joined #launchpad [09:34] jamesh: hi, could you do a fast review for me? [09:34] jamesh: I forgot to add support for koffice in the branch you reviewed yesterday [09:34] jamesh: https://devpad.canonical.com/~andrew/paste/fileK6LECC.html [09:37] carlos: looks okay [09:37] ok, thanks [09:51] carlos: the Punjabi stuff is interesting [09:52] jordi: and confusing... [09:52] because we did unify the effort a while back :( [09:52] I'm not happy about splitting it again. [09:52] well, if there is a valid language code (seems to it) [09:52] and both teams are not able to work together... [09:52] we cannot force them to do it [09:53] It's not exactly like es_ES vs es [09:53] I know [09:53] it's quite similar, but not the same [09:53] so... [09:53] I need more info regarding their inability to work together [09:53] there were argentinians claiming they couldn't contribute to es at some point [09:54] I want to make sure they really can't "understand each other" [09:54] sure [09:54] we should try to convince them, but if we reach a point when they say 'no way' we cannot force them to do it [09:55] woa, and kopete is also sweet [09:55] yeah, I agree [09:55] I want more opinions from the area though [09:56] sure [09:56] Debian or GNOME Punjabi teams [09:56] that's also something to talk with that guy, if he really sees that we should split, he should start doing it in GNOME and KDE too [09:57] so we don't start having problems with upstream [09:59] stub: hi, if you already saw my cherrypick request, I would like to ask you some extra minutes to get another merger request accepted by PQM, it's related to that cherry pick, but I forgot to add that code there, it adds support for KOffice layout === Seveas [n=seveas@ubuntu/member/seveas] has joined #launchpad [10:20] danilos, carlos: short meeting in 10 mins? [10:21] SteveA: sure [10:21] SteveA: sure [10:21] ok, thanks. [10:25] SteveA: should I be there? [10:25] "jordi, the social guy" :P [10:26] jordi: this is a specific meeting with mpt about some 1.0 ui stuff [10:26] so you don't need to be involved [10:27] it's more about the technicalities of searching and when some specs are scheduled [10:27] SteveA: okay [10:27] danilos: dude shuddup [10:27] :) [10:32] morning [10:32] bug 44 [10:32] Malone bug 44 in rosetta "Messages should be searchable." [Wishlist,Confirmed] http://launchpad.net/bugs/44 === Seveas [n=seveas@ubuntu/member/seveas] has joined #launchpad === malcc [n=malcolm@host86-138-251-144.range86-138.btcentralplus.com] has joined #launchpad === Spads [n=crack@217.205.109.249] has joined #launchpad === jinty [n=jinty@132.Red-83-55-196.dynamicIP.rima-tde.net] has joined #launchpad [11:07] carlos: ok === ryanakca [n=ryan@d226-26-139.home.cgocable.net] has joined #launchpad [11:07] stub: the merge is done, and the new revision number in your inbox [11:08] stub: thank you === BjornT [n=bjorn@clt-84-32-240-183.dtiltas.lt] has joined #launchpad [11:50] New bug: #59318 in launchpad ".changes file should be displayed too" [Untriaged,Unconfirmed] http://launchpad.net/bugs/59318 [11:59] malcc: ping [12:06] SteveA: pong === seb128 [n=seb128@ubuntu/member/seb128] has joined #launchpad [12:18] malcc: I had an idea about the __eq__ sets thing. see list [12:19] SteveA: I saw. I don't think it can be that, as that would have fooled my debugging too - I was only able to confirm this was caused by them being different objects because they repr()ed with different ids [12:22] in that case, my recommendation is to work around it explicitly using obj.id for now, and know that this will be fixed when we upgrade to a better ORM [12:23] the correct way to implement __eq__ involves taking into account object class, object id and database connection id. [12:23] but, given the hairiness of sqlobject connection handling, i think implementing it properly will be error-prone [12:23] so, it's better to use the minimum needed in the code where it is needed [12:24] maybe implement __eq__ based on object id, and make it raise a warning, or even raise an exception [12:24] what do you think? [12:24] Hmm, yes [12:25] Making it raise would be bad [12:25] No more SQLObjects in sets at all, even if you can be sure of the comparison issues in your particular case...? [12:26] Is there any reason why we can't implement __eq__ according to those criteria? [12:26] I think your ideal comparison is the right one [12:26] type comparison, object.id comparison, check the connection cache to ensure both objects are in the current cache [12:26] Yes, stub's question is the right one - if we can do the right thing, we should. If we can't, I'm not sure which of the workarounds is best, possibly just leaving well alone and noting the issues [12:28] malcc: we shouldn't use sqlobjects in sets if they're not implementing __eq__ properly [12:29] stub: I don't know about checking theyre in the current cache. we'd just check they have the same connection [12:29] but, it is a bug today, right now, to use __eq__ on a database object [12:29] unless you specifically mean "this very object Ihave here" [12:29] rather than "the object from the current connection with this class and this id" [12:30] SteveA: If that's how SQLObject is supposed to work, then yes, using __eq__ is a bug. [12:31] SteveA: I thought it was supposed to unique these things, in which case we've exposed a SQLObject uniquing bug here instead [12:31] what does "to unique these things" mean? [12:32] To ensure that there can only be one object in any one transaction representing any one database row [12:32] ok, to ensure uniqueness [12:32] sqlobject doesn't do that [12:32] it does it *a bit* [12:32] enough to lull you into a false sense of security [12:32] Cool! [12:32] but it isn't designed to do it thoroughly [12:32] SteveA: If there is a back reference to the connection in the object, sure. But I thought we would have to ask the connection if the object is valid (which means it is in the connections cache) (?) [12:32] another reason to use a better-designed ORM [12:33] stub: there is a kinda back-reference, but now we're getting into horrible hairy territory. [12:33] stub: so maybe your plan of making it only work for the current cache is a good one [12:33] stub: I still think that this issue is too hairy for sqlobject, and we should make people use obj.id [12:34] but I think I may be too extreme to be practical there [12:34] Well, given it doesn't work properly, we might not actually have that many places comparing SQLObjects with == [12:35] I don't think we will be worse off if we just implement __eq__ checking for just id and class equality either. If the developer uses objects from previous transactions, then the obj.id == ob2.id comparison won't stop that happening either. [12:35] malcc: Wouldn't that fall back to id(obj) == id(obj2), which would often work by accident? [12:39] stub: Yes, I guess it would often work [12:39] i think comparing SQLObject with == is quite frequent in our code base, so most of the time it seems to work. [12:41] I think ignoring connections and making == mean "represents the same row" is winning at the moment, for me [12:42] Hmm, or forcing everyone to use id. I'm so indecisive today! [12:42] I'm having one of those days when I shouldn't be allowed to develop === stub is having one of those weeks === ddaa [n=ddaa@82.241.238.155] has joined #launchpad [01:07] ok, let's define that two database objects are equal if they are of the same class and have the same obj.id. [01:07] at least then, we know what we want to happen, rather than have a kinda random situation. [01:07] who wants to implement this, with tests of __eq__, __ne__ and __hash__ ? [01:10] SteveA: I suggest a further email to the launchpad list before implementation; several people on that thread aren't awake yet [01:11] let's cover it in the meeting === lbm [n=lbm@89.150.65.13] has joined #launchpad === mdke_ [n=matt@81-179-118-187.dsl.pipex.com] has joined #launchpad === cprov-afk is now known as cprov === Fujitsu [n=Fujitsu@ubuntu/member/fujitsu] has joined #launchpad === Ubug2 [n=bugbot@ubuntu/bot/ubugtu] has joined #launchpad === sabdfl [n=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has joined #launchpad [01:47] evening all [01:47] hey mark [01:50] Argh... its Thursday! [01:50] Meeting in 10 mins I guess [01:50] Or do we get to cancel due to a lack of brazilians? === stub crosses his fingers [01:51] yo [01:52] stub: there's still the meeting [01:52] and there will be some brazilians here [01:54] oh it is thursday [01:55] New bug: #59330 in rosetta "Request: Mark string as "translation is not necessary"" [Untriaged,Unconfirmed] http://launchpad.net/bugs/59330 === mpt wakes up reluctantly === stub wonders wtf his week went [01:57] stub: You saw the query timings I sent you? Will removing the distinct speed up the query that much? [01:58] i.e. old one: https://devpad.canonical.com/~andrew/paste/fileQJI0RU.html [01:58] bradb: Nothing significant. [01:58] vs. new one: https://devpad.canonical.com/~andrew/paste/fileYuSRa7.html (less the distinct) === lfittl [n=lfittl@85-125-149-213.dynamic.xdsl-line.inode.at] has joined #launchpad [01:58] the new one is quite a bit slower [01:59] ooh [01:59] it's that time of week again [01:59] LAUNCHPAD DEVELOPMENT MEETING [01:59] welcome to today's meeting [01:59] who's present today? [01:59] M.E. [01:59] me [01:59] me [02:00] * Andrew: on leave (2006-09-07) [02:00] * Matsubara: on leave (2006-09-07) [02:00] * Kiko: on leave [02:00] * James [02:00] me [02:00] bradb: Myalgic Encephalomyelitis? [02:00] me [02:00] me [02:00] sounds painful [02:01] stub: ? [02:01] carlos: ping [02:01] here [02:01] jordi: ? [02:01] here [02:01] hi ddaa [02:01] let's go [02:01] no francis? [02:01] me [02:01] hey! [02:01] == Agenda == [02:01] * Roll call * Agenda * Next meeting * Activity reports * Actions from last meeting * Oops report (Matsubara) * Bug report report (mpt) * Production and staging (Stuart) * Launchpad 1.0 status reports * Sysadmin requests [02:01] I0m here [02:01] ---- * SQL object equality (Steve) * (other items) [02:01] hmm [02:01] irssi... [02:01] ---- * Keep, Bag, Change * Three sentences [02:02] next meeting -- next thursday as usual? [02:02] any public holidays etc? [02:02] mpt: would you set the channel title accordingly please? === kiko [n=kiko@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [02:02] (I don't know how to drive that in irssi) [02:02] hey kiko === flacoste [n=francis@modemcable207.210-200-24.mc.videotron.ca] has joined #launchpad [02:02] wasn't expecting you today [02:02] I missed you all [02:02] (stevea: /topic ) [02:02] kiko: :) [02:02] and I came to pimp my picture up at www.bigbiker.com.br [02:03] anyway sorry for interrupting [02:03] me [02:03] * Activity reports [02:03] me [02:03] who's hot an dwho's not === SteveA is not hot. [02:03] up to date (finally!) [02:03] up to date [02:03] not hot but on vacation [02:03] up to date [02:03] behind again [02:03] I'm hot! [02:03] I'm up to date [02:03] up to date [02:03] up to date [02:03] (just that I caught up :() [02:03] up to date [02:04] not up, will send summary [02:04] * Actions from last meeting [02:05] * SteveA to update infrastructure specs if /$name is needed for 1.0 [02:05] still to do. it is needed. [02:05] * stub to check that bug 57474 isn't an SQL injection attack vector [02:05] Malone bug 57474 in launchpad "Passing a list as the query string in the product search field crashes ftq" [High,Confirmed] http://launchpad.net/bugs/57474 [02:05] * SteveA to put up a wiki page for the launchpad project to note disaster scenarios on, and mail the list about it [02:05] still to do [02:05] Didn't do that :-( [02:05] actions for steve and stub [02:05] * Oops report (Matsubara) [02:06] SteveA, he sent us the report through mail, will you proxy? [02:06] yes [02:07] the following is from matsubara: [02:07] here's the OOPS bugs that I think it would be worth mentioning in the meeting: [02:07] This is a really weird bug that causes repeated calendar subscribers to appear [02:07] in the portlet because of that it issues insane amounts of SQL queries: [02:07] https://launchpad.net/products/launchpad-cal/+bug/57762 [02:07] Malone bug 57762 in launchpad-cal "Calendar subscription portlet shows lots of repeated subscriptions." [Medium,Confirmed] [02:07] [02:07] we need to remove the calendar from view, as part of 1.0 [02:07] so I propose simply removing that portlet [02:08] Broken links to sourcepackages in the +packages page: [02:08] https://launchpad.net/products/soyuz/+bug/50399 [02:08] Malone bug 50399 in soyuz "Broken links at /people/$person/+packages" [Medium,Confirmed] [02:08] SteveA: will we lose the calendar? [02:08] carlos: yes [02:08]