=== Hawkeye1 [i=Hawkeye@ppp-164-5.26-151.libero.it] has joined #launchpad === jbailey [n=jbailey@modemcable139.249-203-24.mc.videotron.ca] has joined #launchpad [12:25] https://launchpad.net/distros/ubuntu/+source/evolution is telling me I don't have access to this page. [12:26] https://launchpad.net/distros/ubuntu/+source/evolution-data-server works fine, however. === mdz [n=mdz@studiocity-motorola-bsr1-70-36-194-85.vnnyca.adelphia.net] has joined #launchpad [12:36] jbailey: confirmed here [12:36] raphink: Thanks, I'm filing it now. [12:36] :) [12:36] raphink: Will you confirm bug 31573 please? [12:36] malone bug 31573 in launchpad "Evolution source package in Ubuntu page tells me I don't have access" [Normal,Unconfirmed] http://launchpad.net/bugs/31573 [12:37] Ubugtu: Thanks. [12:37] jbailey: done [12:38] raphink: Thanks. === dsaa [n=dsaa@210.5.92.197] has joined #launchpad [01:00] Goooooooooooooooooooooood afternoon Launchpadders! [01:02] hmm hello mpt === mdke_ [n=matt@ubuntu/member/mdke] has joined #launchpad [01:02] hi [01:03] good night === jsgotangco [n=jsg@210.4.38.43] has joined #launchpad === mdke__ [n=matt@81-178-227-166.dsl.pipex.com] has joined #launchpad === spaescowboy [n=rendrv@sjs-130-65-240-155.sjsu.edu] has joined #launchpad === hannosch [i=hannosch@e176108115.adsl.alicedsl.de] has joined #launchpad [01:31] Little game for you === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has left #launchpad [] === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad [01:32] Who can guess what this small icon represents? [01:32] http://ddaa.net/bazaar/emblem6.png [01:32] dog doing its business [01:33] lifeless: I cannot imagine how you manage to see that... === mpt [n=mpt@219-89-150-174.jetstart.xtra.co.nz] has joined #launchpad [01:33] head in the top left, fire hydrant in bottom right, body between [01:34] mh... maybe an outline would help... [01:34] there's some sort of note, and a brick [01:34] represents? hmm [01:34] heh [01:38] It's meant to say "source code buttress"... [01:38] anybody would half a brain would see it's a flying buttress... [01:42] I do not mean to insult anybody... [01:48] lifeless: by the way, does the launchpad importd stuff handle time going backwards in CVS branch history? [01:49] I think that one is slightly better defined. http://ddaa.net/bazaar/emblem7.png [01:50] spaescowboy: btw, congrats for noticing the carefully tuned brick pattern [01:50] The requested URL /bazaar/emblem7.png was not found on this server. [01:50] fixed === ddaa puts that as the buttsource emblem === Keybuk [n=scott@213-78-32-60.ppp.onetel.net.uk] has joined #launchpad === mpt has NO idea what that is supposed to be [01:52] buttress on source [01:52] tell me, how'm supposed to represent that? [01:53] A dog kissing a document? [01:53] buttress on source [01:53] ok, this is where I admit I don't know what buttress is [01:53] jamesh: FSVO backwards, yes. [01:53] jamesh: date stamp skew we should be quite robust on [01:54] oh, yeah, I actually see the dog, cute... [01:54] jamesh: popping revisions of the end we are not. [01:54] ddaa: see! [01:54] lifeless: but he does not see an hydrant, he sees a dog [01:55] I've not yet completely lost faith in my graphic abilities, I'm going to inflict a few more of those on you. [01:55] lifeless: okay. I found that the CVS -> Subversion conversion script they're using for gnome doesn't seem to be so robust: http://mail.gnome.org/archives/gnome-hackers/2006-February/msg00078.html [01:56] jamesh: that sort of historical thing we should be pretty much immune to [01:56] jamesh: I spent ages on it, and though I've thought of an even better way now, its still seriously robust [01:56] nice [01:56] jamesh: it even handles revision-date loops [01:56] i.e. file A: rev 1.1 Time 1 message A, rev 1.2 Time 2 message B [01:57] I found that Tailor seems to have problems with date skew too [01:57] file B: rev 1.1 Time 2 message B, rev 1.2 Time 1 message A [01:57] we will handle that correctly. [01:57] by generating 3 revisions [01:57] rev 1: File A 1.1, file B not present [01:58] rev 2: File A 1.2, File B 1.1 [01:58] rev 3: File A 1.2 File B 1.2 [01:58] (yes thats an impossible corner case, but it represents a class of loops I've seen in the wild) [01:59] yes, I have no faith in Tailor or cvs2svn [01:59] As a one-shot system they are both fixable but AFAIK they are not fixed. [02:00] If you guys can wait for the bzr versions of importd I think you'll get much better results. [02:01] They seem set on doing the conversion middle of march :( [02:01] fork jhbuild to bzr :) [02:01] I'm planning to [02:02] I'm going nose-down for a while, back at a convenient break [02:02] I did a Tailor conversion after fixing the RCS files with vi :) [02:03] The python cvs -> svn conversion has some annoying problem with dates from its conversion: http://mail.python.org/pipermail/python-dev/2005-November/058269.html === ddaa chuckles [02:04] pathological but good example why repository-wide revno is a booooooorken idea... [02:06] spiv: unless the operator did something really stupid, cscvs should be able not to care, since we will only convert chunks where the timestamps should be monotonically increasing. [02:06] ddaa: I just assumed that cscvs would do a better job :) [02:06] Well, I do not have to. [02:07] The breakage is linked to svn broken model. [02:07] Since cscvs does not convert _to_ svn it cannot have this problem. [02:07] ddaa, since you're awake now (why?), should we discuss RCS imports? [02:08] I'm awake because I spent a couple of hours drawing a buttsource emblem [02:08] mpt: let's talk about it [02:08] So, I'm perhaps in a good position here, because I know almost nothing about this subject [02:09] you might have noticed that for a few days I've been ranting/bitching/pleading for various changes to the productseries model in the mailing list and the bugtracker. [02:09] yes [02:09] Is this the sort of thing where a spec would be useful to tie all the design details together and ensure they work as a whole? [02:10] or would that be a net waste of time? [02:10] basically, I want to convince you because I think a few important UI model changes are needed, so it's going to go through you in the end anyway. [02:10] Mh... maybe a spec would be useful... [02:11] there's at least two idea in the air so far. [02:11] (at first there was only one, but Keybuk generously suggested another one) [02:12] ok. Why does Launchpad care about RCS stuff at all? [02:12] mpt: because a large part of my job is converting upstream RCS repositories (CVS an SVN currently) into Bazaar branches. [02:13] why? [02:13] what are the resulting Bazaar branches useful for? [02:13] at least two things [02:13] (btw we seem to have on this already) [02:14] this spec is just a minor bit [02:14] One of the important pages is https://wiki.launchpad.canonical.com/TheBazaar [02:15] So, the grand plan is that in the end [02:15] the source code for most major open source projects will have its history in bzr branches [02:15] that will be used by HCT [02:16] to allow packagers to easily share patches across distribution boundaries [02:16] ok [02:16] There's a dizzying number in moving parts involved in getting there, so I'm not going to get in the detail. [02:17] One aspect of that grand plan is importing a fine-grained revision history of upstream projects into bzr. [02:18] Automatic RCS imports are also instrumental in delivering GrumpyGroundhog. [02:18] ok [02:19] A more immediate use case for normal people is using bzr to hack on projects that care nothing about bzr. [02:19] That's also a good thing to "subvert" the projects into using bzr progressively. [02:19] (wow, this is a whole world of specs I've never seen before) [02:21] One scenario would be that a few devs start hacking on bzr for their own convenience, publish their branch, and slowly all members of the project gain awareness of bzr benefits. [02:21] right [02:22] eventually, the core devels say "okay now that branch is mainline" and the RCS import becomes history. [02:23] nifty [02:23] Or not, but a subset of the hackers can still use bzr to collaborate and prepare patches to send to core devs. [02:24] So, that's a big big projects which has been in the works ever since the company exists. And has suffered delays for many many reasons. [02:24] Mostly reasons like "it's a really complex and hard problem" [02:24] mpt: so are the use cases clear to you, now? [02:25] yep [02:26] Since the project has been in the work for so long, it has accreted a stupendous amount of cruft. [02:26] To set up a RCS import, at the moment [02:26] one has to create a ProductSeries. [02:27] The main purpose of a ProductSeries is to model how big projects maintain parallel lines of development, like apache1 and apache2, or the major versions of postgres, or the various branches of automake. [02:28] For the most part, these "series" have a life of their own, their are projects inside the project. [02:29] ok [02:29] mpt: that's the point where you can start to smell an attempt to "model the open-source world". [02:29] So do some products not have product series in the real world? [02:29] most of them don't [02:30] projects only develop series when they grow big enough to spare resources on maintaining stable branches [02:31] most projects just work on a main branch, make a release (though many do not even do that) and move on [02:31] so at the moment you're creating fake product series for these products? [02:32] Yeah that's one of the issues. Many project have only one series, called various names like "main", "trunk", "head", "1.0", etc. === suodla is now known as dous [02:33] For such projects, the series is just an extra layer of indirection. [02:33] The project has a whole has releases, has packages, translations, etc. but it needs a series just to access those features. [02:34] This seems a bit analagous to translations, where a bunch of things have only one template [02:34] requiring an extra click [02:34] I know nothing about translations... [02:36] So one of the ideas would be giving Products an implicit ProductSeries [02:36] which could have a NULL name, or some reserved name like "main". [02:37] That would allow presenting the features for that ProductSeries as if they were features of the Product itself. [02:37] ok [02:38] Another issue, one that's more important to me because I think it's not just a UI issue, but really a model bug [02:38] is the way RCS imports are coupled to ProductSeries [02:38] ATM, a ProductSeries has 0 or 1 RCS import defined within it. [02:38] The only way to set up a RCS import is to create a ProductSeries. [02:39] Can you see the hidden assumption? [02:40] apart from that all products must have product series? [02:41] The hidden assumption is that: RCS imports are only used for foreign repositories which are used to cut releases. [02:42] and not for ...? [02:42] and not for branch that developpers use to collaborate [02:43] or for branch that they use for any godforsaken reason the devels came up with... [02:44] I have a couple of practical use cases, and a plausible future use case. [02:44] Practical use case: gnome-app-install [02:44] mvo used to work on gnome-app-install on the GNOME CVS [02:44] now he switched to bzr [02:44] and now uses bzr instead [02:45] yet he still keeps the CVS around and wants it updated [02:45] because that the communication channel with the GNOME translation team. [02:45] Nothing to do with releases. [02:45] so he wants a bzr export, rather than an import? [02:46] mpt: syncing the CVS with bzr is his problem. [02:46] it's not possible to do it in the general case anyway [02:47] It's just an example of why a RCS import can be something else than a branch used to make releases. [02:47] ok. [02:47] Another real world use case: [02:47] Some projects, I do not remember which ones, create one branch for each release. [02:48] They supposedly use that branch to do the stabilisation work. [02:48] Here the branch are used to do releases, but they are not release series. [02:48] Mozilla does that, aiui [02:49] Actually, the branch for the release series should probably be something like a branch maintained by Dyson, the tarball importer, merging from the RCS import branches for each release. [02:50] Another real world use case: [02:50] some projects are unconscious enough to actually use CVS for feature branches. [02:51] Again, nothing to do with releases. [02:51] unconscious? :-) [02:51] out of their mind, immune to pain, whatever [02:52] mpt: are those use case clear to you? [02:53] * those use cases [02:54] the one about a branch for each release isn't entirely clear [02:54] Are you saying we might want to import one release, but not the other releases in that series? [02:54] BTW, I'm not sure that mozilla is a good example. Their minor releases are probably treated as release series by packages. [02:55] mpt: I'm saying that for some project, a release series would actually be associated to a collection of RCS imports. === stub [n=stub@gb.ja.97.57.revip.asianet.co.th] has joined #launchpad [02:56] The actually branch representing the series would be merging from those rcs import branches. There's actually a tool out there that's supposedly able to find out which imported revision is closest to a tarball. [02:56] It's called Dyson, coded by Keybuk. [02:56] now the responsibility of niemeyer [02:57] ok. [02:57] Now my pet use case: [02:58] when we implement imports from other DVCS [02:58] (because it's "when", not "if") [02:58] there will actually be a need for RCS imports for any random hacker's branch. [02:59] even people who are not owners of the product [02:59] Currently, the fact that RCS import is couple to a ProductSeries couples the ownership of the import to the ownership of the product. [03:00] That has not been a problem so far to be honest. But I think mainly because RCS imports did not have a lot of public adoption for a variety of reasons. [03:01] ahh [03:01] so this is for when we're trying to get people to switch from other DVCSes, rather than other CVCSes :-) [03:01] Also, examination of the Branch.url specified by the users show interesting things. [03:02] I noticed at least one branch whose URL was set to a SVN repository. [03:03] That's supposed to be an URL of a page that describes the branch, correct? [03:03] No, that's supposed to be the URL of a bzr branch out there, that can be checked out using "bzr get". [03:03] The user got the checkout bit right. [03:04] So back to mvo's use case. [03:05] In an ideal world, he would detach the CVS import from the productseries, and attach his bzr branch to the productseries. [03:06] He does not need or want a productseries for the CVS import. That would be just confusing to people. He's just interested in the RCS import service. [03:06] Is his bzr branch really managing a product series, or is it just the product in general too? [03:06] In my understanding, it's the product in general. [03:07] The gist of my argument is: "RCS import is a useful service by its own". [03:07] coupling it artificially to some other concept only reduces the ability of the system to answer the answer the user needs accurately. [03:08] Are you saying it shouldn't need attaching to a product series *or* a product? [03:08] Mh [03:08] I think it would be good to require that a RCS import is always attached to a product. [03:09] If only to help people find them. [03:09] Also because I expect they are only needed for projects large enough to need a product. [03:10] But actually, I'd like to see the RCS import to be "just another kind of branch". [03:10] It's just a branch in another VCS than bzr. That we make available in bzr format. [03:11] ok. [03:11] I think I've finished my diatribe. [03:11] So how does all of this involve me? :-) [03:12] This is all about users and use cases. [03:12] You are the UI nazi. [03:13] I would not involve you in deeply technical issues of RCS import publishing for example. [03:13] But this is an issues with important consequences on the user experience. [03:14] all right [03:14] So I believe that if take position in that discussion, that would have a large impact. [03:14] * if you take position [03:14] so this needs a spec with a name like RcsImportsWithoutSeries? [03:15] Sounds right to me. [03:15] ok [03:16] Thanks for your attention. [03:16] thanks for your explanation [03:16] I understand more about Launchpad now [03:17] I believe we need to keep ProductSeries in the datamodel, because there are a number of large high profile projects that need it. However I'm all for hiding it in the UI for the bulk of our small projects. [03:17] you're welcome, on my last performance evaluation lifeless said I was not asking for help often enough [03:17] now I feel like I spending most of time giving work to other people :) [03:17] oops [03:17] now I feel like I am spending most of my time giving work to other people :) [03:17] ddaa: Keep that up and you will become a manager :) [03:18] stub: ack++ ProductSeries is really useful in some cases. [03:19] it just has some sort of over-inflated sense of its self-importance at the moment [03:20] so I'd like to beat it back in the rank === mdz [n=mdz@studiocity-motorola-bsr1-70-36-194-85.vnnyca.adelphia.net] has joined #launchpad === stub kicks breezy-backports === ddaa goes sack potato [03:39] ddaa: before you go [03:39] mpt too [03:39] we are doing the RCS imports to aid collaboration of developers on Ubuntu [03:39] zzzzzz pong zzzzzzz [03:40] non-ubuntu included projects, and unrelated projects are really not very interesting from that perspective. [03:40] yes, we are not turning people down, and I'm not suggesting we should start doing that [03:41] but I do want to ensure we don't forget *why* we are doing this: its not to get people to migrate to bzr (one-shot converters are _MUCH_ easier) - its to allow hct, and grumpy to be effective. [03:41] that is all [03:41] ok [03:41] that was not really the perspective I had [03:41] I realize that ubuntu is the main client of rcs imports at the moment [03:42] ubuntu is the reason we are doing rcs imports at all [03:43] go sleep now, sorry for disturbing just as you disappeared. [03:43] I thought they were doing ubuntu to bootstrap rcs imports and hct ;) [03:44] (well, actually the plan did sound like that to me, back then) [03:46] which is also consistent with who where the two first hires [03:46] first hire was dave miller [03:47] oh really, I thought it was you [03:47] for bugtracking for the distro [03:47] second was me, for VCS for the distro [03:47] third? [03:47] jdub or scott, I can't remember which. it was about then Mark went critical mass on hiring [03:48] yeah, he did that two or three times :) that was fun === ddaa -> bed, really [03:51] The sooner someone reviews my trivial/ branch, the fewer duplicate bug reports we'll get... [03:51] especially from Dino Solon A. Agcambot [03:52] did he strike again? === dsaa [n=dsaa@210.1.81.82] has joined #launchpad [03:53] yeah [03:54] Should we track the London Launchpad workshop as a sprint in Launchpad? [03:54] I don't think we're doing spec work there [03:55] and linking specs to sprints is about the only thing you can do with sprints in LP === OgMaciel [n=omaciel@ubuntu/member/gnukemist] has joined #launchpad [03:56] yyyyeah === mpt resists the urge to link a Launchpad spec to FOSDEM 2006 [03:57] hi... I'm trying to register a new team but don't really undertand the contact email field... is that an existing email address? I assumed that was the answer but it won't let me re-use my own email [03:58] OgMaciel: if you don't set a contact email for a team, then correspondence to the team will be mailed to each member individually [03:58] jamesh, I'd like to have the emails sent to me... how can I do this? [03:58] OgMaciel: if there is a mailing list you'd like correspondence for the team sent to, set it as the team's contact email address [03:58] OgMaciel: and no one else on the team? [03:59] why? [03:59] jamesh, don't have one yet... [03:59] jamesh, I figured I'd get emails about administrative stuff [03:59] jamesh, just don't want to bother the other members [03:59] OgMaciel: the common use case is to set the team as a bug subscriber [03:59] jamesh, cool... thanks [04:00] in which case you'd want all team members to get the mail [04:00] hmm, that could be a bit more obvious [04:00] mpt, agreed [04:02] dsaa: reporting the same bug multiple times does not get it fixed quicker [04:03] Why is "a new message ... sent to this address with instructions on how to finish its registration" anyway? [04:03] That looks like residue from registering a person. It doesn't make sense for registering a team. [04:05] mpt, actually, I just registered a team but didn't get an email === poningru [n=poningru@n128-227-34-184.xlate.ufl.edu] has joined #launchpad [04:12] OgMaciel, reported bug 31590 [04:12] malone bug 31590 in launchpad "Contact e-mail address entry for new team should be more obvious" [Normal,Unconfirmed] http://launchpad.net/bugs/31590 [04:14] mpt, can you link me please? [04:17] "link you"? [04:18] You mean give the bug report URL? That's what Ubugtu's for ^^ [04:18] mpt, link to the bug... but it's ok [04:19] mpt, never used Ubugtu [04:19] read up [04:19] mpt, thanx [04:20] mpt, I can read (I bet it is something like !ubugtu bug#) but am going to Malone anyhow [04:20] Ubugtu: 31590 [04:20] nah [04:20] its bug #31590 [04:20] malone bug 31590 in launchpad "Contact e-mail address entry for new team should be more obvious" [Normal,Unconfirmed] http://launchpad.net/bugs/31590 [04:21] OgMaciel: the URL is on the right hand side [04:21] lifeless, am there already... thanks ;) === LaserJock [n=mantha@ubuntu/member/laserjock] has joined #launchpad === OgMaciel [n=omaciel@ubuntu/member/gnukemist] has left #launchpad ["Leaving"] === mpt [n=mpt@219-89-150-174.jetstart.xtra.co.nz] has joined #launchpad [05:35] Both before and after updating sqlobject, I get * Module canonical.lp.z3batching, line 41, in __init__ [05:35] listlength = list.count() [05:35] ForbiddenAttribute: ('count', ) [05:35] (that's after make clean and make schema, too) [05:39] mpt: is your sqlos up to date? [05:39] I hadn't updated that specifically === mpt tries [05:42] That worked, thanks jamesh === skippydog [i=user@CPE-65-31-168-17.wi.res.rr.com] has joined #launchpad === skippydog [i=user@CPE-65-31-168-17.wi.res.rr.com] has left #launchpad [] === skippydawg [i=user@CPE-65-31-168-17.wi.res.rr.com] has joined #launchpad === skippydawg [i=user@CPE-65-31-168-17.wi.res.rr.com] has left #launchpad [] === mpt [n=mpt@219-89-134-3.jetstart.xtra.co.nz] has joined #launchpad === mruiz [n=mruiz@pc-31-66-104-200.cm.vtr.net] has joined #launchpad [06:34] hi! someone can help me? I made a project by error. Can I erase it? [06:35] Merge to devel/launchpad/: [trivial] Restore logtail to builder page (r3150: Matthew Paul Thomas) [06:36] mruiz: stub can. [06:36] Whats the project name? [06:36] spiv: thanks [06:36] stub: ubuntu-cl [06:38] Gone [06:38] stub: thanks! [06:41] mpt: Is there any reason we might want to prefer /++resource++foo.png URLs to /@@/foo.png URLs ? I was just about to land a search and replace making things consistant but thought I'd better check. [06:44] stub, no reason that I know of [06:44] I've just been shortening them as I find them [06:45] ok. as long as I'm not breaking your syntax highlighting or triggering a Netscape 4alpha2 bug [06:46] stub: did that sqlobject fragment help with the person_sort_key stuff? [06:47] jamesh: Haven't tried it yet but it looks perfect [06:48] stub: seems that sqlobject only does those colunm name checks if orderBy is a string (or list of strings) [06:48] other sqlbuilder expressions get passed through as is === LaserJock [n=mantha@ubuntu/member/laserjock] has left #launchpad [] [07:21] hi [07:26] Merge to devel/launchpad/: [trivial] Consistently use preferred /@@/ syntax instead of ++resource++ in resource URLs (r3151: Stuart Bishop) [07:32] stub: we could call /@@/ anything -- such as "resources" or "images" if we want [07:34] ack === LaserJock_away [n=mantha@ubuntu/member/laserjock] has joined #launchpad [07:37] does anybody know what "Users can spoil their votes?" mean for a LP poll? === LaserJock_away [n=mantha@ubuntu/member/laserjock] has left #launchpad [] === mdke [n=matt@ubuntu/member/mdke] has joined #launchpad === Link9618 [i=Link@ppp-67-125-120-33.dialup.irvnca.pacbell.net] has joined #launchpad [07:53] Where is the Passwd when I sign up === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === mpt_ [n=mpt@219-89-155-10.jetstart.xtra.co.nz] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad [08:23] So how does this @ubuntu/member/foo IRC thing work? === ulinskie [n=yolynne@202.57.88.34] has joined #launchpad === carlos [n=carlos@84.76.255.40] has joined #launchpad [08:35] morning [08:38] hello [08:47] hey, carlos [08:47] SteveA: hi [08:48] stub: one way is that you give freenode money, and they give you a fancy pseudo-domain [08:48] stub: the other is that you can somehow register your affiliation with some group that is registered with freenode [08:48] carlos: have you seen the spreadsheet i sent to the list, about rosetta queries? [08:49] SteveA: I have the ajax branch working but not finished and without tests. Kiko asked me to stop it for a while and ask for a review of what I have atm. Do you want to do that review? (not now, when you have some time) [08:50] SteveA: I saw the email, yes, I'm going to work on that now after some DB changes I need to request to stub [08:50] sure, i'll do the review. let's look next week [08:50] i'm very excited that we may be able to get +translate pages working twice as fast TODAY [09:21] SteveA, call? [09:22] SteveA: I was wondering if there was an official Ubuntu freenode group given the ubuntu/member bit. Perhaps for all Ubunteros or something. [09:23] nah, i think for anyone who claims to be interested in ubuntu [09:24] mpt_: sure, 5 mins? [09:25] ok === nitishp [n=nitishp@adsl-68-126-216-0.dsl.pltn13.pacbell.net] has joined #launchpad [09:32] You guys rock! [09:34] hi nitishp. thanks for the feedback. although, i want to say that we only rock some of the time, we actually suck some of the time too. === mdke_ [n=matt@ubuntu/member/mdke] has joined #launchpad === mdke_ [n=matt@ubuntu/member/mdke] has joined #launchpad [10:15] morning === Lorenzod [n=lorenzod@63.218.103.162] has joined #launchpad [10:36] Merge to devel/launchpad/: [trivial] Added Akan plural forms (r3152: Carlos Perell Marn) [10:38] daf: morning [10:45] carlos: about the optimisation... [10:45] SteveA: any problem? [10:45] what i'd like to do first is to just optimize that one query that would provide the most savings [10:45] and nothing else [10:45] do you think you can do that? [10:46] then i can review it [10:46] and i can also help, if there are any things you need help with doing it [10:46] yes, I wil do it, don't worry [10:47] and then we can see about what we should do next [10:47] s/wil/will/ [10:47] the point is, i don't want us to rush in and optimise more than that one thing to start with [10:48] daf: on the bug report email [10:49] what i'm most concerned about for today's meeting is having the OOPS bugs listed, and ensuring that an appropriate person is assigned to each [10:50] there are just 17 oops bugs [10:50] do you think we can go through them all in the meeting? [10:51] yes === dsaa [n=dsaa@210.213.76.158] has joined #launchpad [10:55] SteveA: I think the COUNT query you are talking about in your email is related to statistics updates [10:56] even so... [10:56] Instead of caching, I could try to improve that code so we don't do a select COUNT every time, just a field update [10:56] can you point me at the code in question? [10:56] sure, just a second [10:58] SteveA: database/pofile.py#updateStatistics (line 467) [11:00] SteveA: we execute it with every message on the submit === WaterSevenUb [n=WaterSev@azevedo.astro.up.pt] has joined #launchpad [11:02] SteveA: the first optimization I can think on is execute it once per submit instead of once per entry changed [11:03] in the worst case (all entries changed), instead of executing it ten times we will execute it just once [11:03] in the best case (none is changed), we will execute it once instead of none but I suppose I should be able to figure a way to reduce this to zero too [11:03] this COUNT query is the longest one? [11:05] daf: that method is not raising just one query but three or four [11:05] daf: count queries [11:06] ah, got the spreadsheet now [11:07] you think it's possible to replace these three SELECT COUNT with one? [11:08] no, those are different counts [11:08] I think it's possible to reduce the number of calls to that method [11:09] ok, so 3 queries instead of 210 [11:09] do it! [11:10] well, I need to check how is that we did 70 queries instead of 10 [11:10] it should be done only once per entry [11:11] ah [11:11] and 10 entries per page is 10 calls to updateStatistics == 30 queries not 210... [11:11] maybe call traceback.print_stack() in updateStatistics()? [11:12] I thought you said "once per submit" [11:12] but I support you meant "once per message submitted" [11:12] suppose [11:12] jamesh: ping [11:14] carlos: looking at those queries, I don't understand why we can't execute them once for every POST [11:14] indeed [11:14] daf: atm is once per message submitted. I want to change it once per submit [11:15] cool [11:15] daf: we can, that's what I'm suggesting ;-) [11:15]