[01:10] hey lifeless [01:10] lifeless: do you know what time the staging update happens? [01:37] sabdfl: not offhand [01:38] sabdfl: sorry [01:38] ok thanks [01:38] night all [01:38] I'm pretty sure stub has mailed that to the lp list [01:38] gnight === LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net] has joined #launchpad === Seveaz [n=seveas@ubuntu/member/seveas] has joined #launchpad === rpedro [n=rpedro@87-196-99-122.net.novis.pt] has joined #launchpad [03:22] good morning [03:23] jamesh: morning. [03:23] jamesh: your laptop made it home ok? [03:23] yeah [03:23] seems to be working fine [03:25] how's the smart server stuff going? [03:26] Slowly, but making progress. There are quite a few tests that assume a local transport, and other little issues. === imbrandon [n=brandon@ubuntu/member/pdpc.active.imbrandon] has joined #launchpad [04:45] what's smart server? [04:58] WebMaven: http://bazaar-vcs.org/SmartServer [04:58] WebMaven: something to speed up bzr's network performance [04:59] WebMaven: at the moment, bzr uses a "dumb server" (i.e. plain SFTP or HTTP, so the server needs no special knowledge of bzr branches) [05:00] a smart server would know what a bzr branch is and know how best to send the client what it needs in minimal round trips and download size [05:00] (hopefully) === imbrandon [n=brandon@ubuntu/member/pdpc.active.imbrandon] has joined #launchpad [05:20] hrm any LP admins arround i can poke for a second === imbrandon thinks it might be too late at night === stub [n=stub@ppp-58.8.4.52.revip2.asianet.co.th] has joined #launchpad [05:23] ok well heres my deal incase anyone wakes up, got a slight problem and dunno if i need to poke yall or Riddell , but a few days ago i changed my main contact email on LP to a new address but my alias's @ubuntu.com / kubuntu.org are still trying to send to the old adress , normaly this wouldent be a problem but the dns entry for the domain my old address is at seems to be cached too so basicly all my mailing list mail and b [05:24] can someone poke the dns to refresh or at very leaste update the alias file to point to my new contact email [05:24] heh === ausimage [n=owner@pool-141-149-239-130.syr.east.verizon.net] has joined #launchpad [05:30] imbrandon: the alias sync stuff isn't automatic at the moment. I'm not sure who you have to ping to get it fixed. [05:30] morning stub [05:30] ahh jamesh thanks , probably riddell he who set me up the first time [05:30] thanks [05:30] Hello, I would like to request the package xdg-utils be added to the ubuntu distro on launchpad... It is a dependency of Lyx now.... bug #56282 and will not upgrade in Edgy. Thanks. [05:30] Malone bug 56282 in lyx "Edgy Dependency Issue" [Untriaged,Unconfirmed] https://launchpad.net/bugs/56282 [05:31] Morning [05:31] ausimage: try in #ubuntu-motu for info about getting new packages in edgy [05:31] stub: no problems with your luggage? [05:31] K crimsun sent me here... [05:32] imbrandon: elmo or possibly Znarl or Spads are the only ones who can poke the email address aliases. [05:32] jamesh: Thankfully no. === ausimage [n=owner@pool-141-149-239-130.syr.east.verizon.net] has left #launchpad [] [05:32] stub: ahh ok, since i'm not arround #launchpad that much whats the "normal" times they are awake/alive ? [05:33] jamesh: I couldn't hear the usual thumps as the Thai baggage handlers toss luggage from the truck to the conveyor belt so maybe they were under special instructions, or maybe feeling generous since it was the queens birthday the day before. [05:33] stub: my flight from Heathrow was almost 2 hours late departing. Thankfully Qantas delayed the Singapore -> Perth flight so that people coming from London could get on [05:34] yeah. I think they were under special instructions everywhere :) [05:34] imbrandon: I'd suggest opening a bug report and assigning it to elmo. They are all on UK time, Znarl earlyish and elmo lateish generally. [05:34] stub: good idea thanks again for yall time for something trivial ;) === crimsun [n=crimsun@pdpc/supporter/silver/crimsun] has joined #launchpad [05:34] jamesh: same same. Arrived at terminal 3 hours before scheduled departure time. 4 hours to get on plane. 5 hours before it started taxiing. [05:35] stub: it took me a while to find the end of the checkin queue because there was another queue in front of it (for passport control) [05:35] stub: by the time I'd checked in, the passport control had gone out the door of the terminal ... [05:36] Hmm... I went straight to checking, then onto the security queue which was like something out of a terry gilliam movie [05:36] (passport queue) [05:36] Every time you turned a corner, it stretched away into the distance. I expected it to go right around and form a loop. [05:36] stub: one last dumbish question , file it against the LP product ? or does it realy matter ...... [05:37] Thankfully, after going the entire length of terminal 3, through a lengthy set of passages, it eventually stopped in the multistory carpark. [05:37] hi, all, just discussed bug 56282 (with ausimage), which will need a sync from Debian Sid, so to file a bug against that source package in LP the name needs to exist. Could 'xdg-utils' be added? [05:37] Malone bug 56282 in lyx "Edgy Dependency Issue" [Untriaged,Unconfirmed] https://launchpad.net/bugs/56282 [05:37] imbrandon: Yes [05:37] after getting my boarding pass/passport checked, it took about 40 minutes or so to make it the last 20-30 metres to the security screening [05:37] stub: ok thanks [05:38] jamesh: same. passport control wasn't the bottleneck for me either - they were letting people through as fast as the queue to screening would let them. [05:39] They seemed too busy to check with dogs or more than a good pat down, so it would have been a good day to be a drug smuggler. [05:39] (Not that anyone would be smuggling drugs out of the UK) [05:40] crimsun: the guys who could answer your question won't be up for a while yet [05:40] jamesh: np, thanks. [05:42] I got my "don't destroy this person's luggage" silver frequent flyer luggage tags in the mail while I was away [05:49] woo [06:05] stub: sounds traumatic [06:05] stub: and we want a conference in the US after this ?! [06:06] I doubt it as they are even more paranoid than the UK. I'll stick that wiki page up (already drafted) [06:28] stub: now we need some publicity [06:28] ;) [06:40] stub: nice page title [06:49] lifeless: are we still planning on moving the LP branches from /home/warthogs/archives/... to somewhere else on the filesystem with shorter paths? [06:49] yes [06:49] I'd love someone else to do that, its not high on my priority list [06:49] - because bzr needs much luv [06:50] I saw the performance comparison page for bzr 0.9 [06:50] congratulations [06:50] thanks [06:50] still a lot to do though [06:51] has anyone done work to teach oprofile how to get python stack frame data ? [06:52] or any vm based machine for that matter (mono etc) [06:52] Hmm, not that I know of. [06:53] I got to grips with it in the weekend [06:53] its really quite nice [06:53] spiv: did you see the review of your short posix-shell-happy branch? [06:54] jamesh: yeah, I did. [06:54] jamesh: that seems like a nice solution. [06:57] spiv: any particular reason you wanted to build launchpad with dash? :) [07:00] jamesh: it is (was?) the default shell on edgy, apparently. [07:00] sivang reported the problem. [07:00] I'm not much of a shell pedant normally, but I figured it would be good to be prepared for when launchpad devs start upgrading to edgy. [07:02] I suppose having a basic bourne shell as /bin/sh isn't that bad an idea :) [07:04] Yeah, and dash is supposed to be considerably faster than bash, so I suppose it might make a measurable difference to boot times and the like. So I'm not shocked that edgy's doing that. [07:05] I guess the other solution would have been an explicit "SHELL=/bin/bash" in that Makefile, come to think of it. That doesn't feel as nice making the shell code cleaner, though. [07:08] dash is definately much faster [07:13] faster startup or faster at running scripts or both? [07:16] both [07:16] its less functional though [07:22] if you call /bin/sh and expect features of bash, your code is broken [07:22] right === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === irvin [n=ipp@ubuntu/member/irvin] has joined #launchpad [08:22] spiv: Does this fix under edgy database/schema/Makefile too? Mark emailed me earlier about it [08:25] stub: sounds like it. [08:31] stub: that's the Makefile it changes, yep. [08:35] spiv: so you'd make sabdfl happy by landing it :) === spiv does so === Spads [n=crack@host-87-74-18-227.bulldogdsl.com] has joined #launchpad [08:49] thanks spivomatic! [08:53] stub: for future reference, what time does the staging update happen? [08:54] after the daily backup is done and copied to the staging server. [08:55] About 1:20 UTC at the moment, give or take 10 mins [08:55] erm... BST. [09:01] ok, thanks === rpedro [n=rpedro@87-196-38-150.net.novis.pt] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === carlos [n=carlos@110.Red-81-39-99.dynamicIP.rima-tde.net] has joined #launchpad [09:25] morning [09:26] stub: hi, around? === danilos [n=danilo@82.117.204.253] has joined #launchpad === marcus_notebook [n=mholthau@71.17.76.83.cust.bluewin.ch] has joined #launchpad === irvin [n=ipp@ubuntu/member/irvin] has joined #launchpad === malcc [n=malcolm@host86-134-233-12.range86-134.btcentralplus.com] has joined #launchpad === Spads [n=crack@82.211.81.249] has joined #launchpad [10:22] carlos: ping [10:22] stub: hi [10:22] stub: what's the status of the migration ? [10:23] carlos: I tried running it on a mirror of the production database. The first run (breezy -> dapper) went fine, and should be fast if I drop the distribution statistics rebuilding. The second run (breezy ->edgy) died with an excepion and I opened a bug on it. [10:23] hmmm [10:23] my fault? [10:24] stub: bug number ? [10:27] Hmm... I have the outgoing email, but it looks like Malone dropped it [10:31] stub: what's it about? === SteveA [n=steve@george.kkhotels.co.uk] has joined #launchpad [10:42] lifeless: ping === jelmer [n=jelmer@a62-251-123-16.adsl.xs4all.nl] has joined #launchpad === SteveA [n=steve@costello.z3u.com] has joined #launchpad [10:58] lifeless: ping [10:58] pong [10:58] hi === doko_ [n=doko@dslb-088-073-081-023.pools.arcor-ip.net] has joined #launchpad [11:08] jamesh: SteveA: tickcount is packaged and should be in NEW now [11:08] I'll do an ITP for debian sometime this week [11:09] lifeless: cool. [11:09] sources are http://people.ubuntu.com/~robertc/tickcount/ if you want to fiddle [11:09] edgy and dapper are quite different for python now - this is packaged for edgy and beyond [11:11] stub: ping [11:11] lifeless: way cool. we need it for both dapper and edgy. [11:11] carlos: edgy migration issues (by stub): https://launchpad.net/bugs/56314 [11:11] ok. I'll need to package it separately for dapper. Do you need 'a binary for dapper' or 'it uploaded to dapper-updates' ? [11:12] danilos: I know, I already talked with him about it [11:12] because the whole point is to deploy it in the DC. [11:12] I'm fixing it right now [11:12] carlos: ok :) [11:12] lifeless: a binary for dapper is okay. [11:12] danilos: sorry for not told you about it [11:12] carlos: np, I've just got the email about it [11:12] lifeless: so I can just ask the admins and launchpad developers to install it [11:12] I'll talk to the sysadmins about their preference then [11:12] thanks lifeless [11:12] they build their own anyway [11:12] so its really whats easiest for them === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad [11:13] also, there is some interest from the support team on taking on small packaging tasks [11:13] so, if you're already fully booked, see if you can pass it along to etienne [11:14] Good morning [11:15] I'm happy to maintain tickcount in ubuntu and debian indefinately [11:15] stub: have you had a chance to look at my bug 30602 mail? [11:15] Malone bug 30602 in rosetta "ERROR IN: https://launchpad.net/distros/ubuntu/dapper/+source/vlc/+pots/vlc/tl/+translate" [Critical,Confirmed] https://launchpad.net/bugs/30602 [11:15] it keeps my hand in to have some packages to care for [11:16] lifeless: fine with me [11:16] however, for doing the dapper backport, I may offer that to etienne as a small task - I dont think hes done binary python modules yet === erdalronahi__ [n=erdal@p508748FB.dip.t-dialin.net] has joined #launchpad [11:17] SteveA: re lifeless being fully booked: you should know he never travels without at least half a dozen brick-sized books, he's pretty much fully booked all the time :) === cprov [n=cprov@monga.dorianet.com.br] has joined #launchpad [11:28] danilos: I found the problem and It's fixed. I'm going to test it on staging now [11:28] carlos: great, hopefully we'll get farther away this time [11:28] carlos: do you have a test for the problem as well? [11:29] It will require sampledata changes so I'm working on it [11:56] lifeless: SteveA: mpool: jamesh: spiv: meeting in 4 mins [12:01] ddaa: on #launchpad-meeting? [12:02] Yes, as usual [12:02] mpool: SteveA: please report to astrometrics^W #launchpad-meeting [12:07] lifeless: hi, could you restart staging's database? I left some tables locked when I killed an external script and I cannot wait until the psql client dies [12:07] well, and Stuart is not around to fix it... [12:09] lifeless: it's unlocked now [12:09] so don't worry about it. Thanks === dsas [n=dean@host86-129-12-249.range86-129.btcentralplus.com] has joined #launchpad [12:47] reviewer meeting in 13 [12:47] lifeless: can you turn off the regex [r=who] thing for the launchpad/ui-one-zero branch please? [12:48] sure [12:48] tell me when you have and I'll resubmit my merge [12:49] done [12:52] ta === dsas [n=dean@host86-129-17-248.range86-129.btcentralplus.com] has joined #launchpad === erdalronahi_ [n=erdal@p508752FB.dip.t-dialin.net] has joined #launchpad === stub [n=stub@ppp-58.8.4.52.revip2.asianet.co.th] has joined #launchpad === sabdfl [n=mark@ubuntu/member/pdpc.silver.sabdfl] has joined #launchpad [01:00] reviewer meeting time [01:00] whos here ? [01:00] me [01:01] me [01:01] * Next meeting [01:01] * Queue status. [01:01] me [01:01] hi [01:02] cool [01:02] 10 items in the queue [01:03] 2 I think shouldn't be there, because they have to go through the bzr process - its double handling to have the lp team review [01:03] not really paying attention, as i'm in meetings [01:03] SteveA: thats fine [01:03] SteveA: you're optional anyhow ;) [01:03] kiko-fud: your branch is reallly getting old - the tt-search branch [01:04] spiv, you have abrnach that is getting a little old [01:04] other than that its all looking fine to me [01:05] oh, next meeting, this time - is that ok ? [01:05] sure. [01:05] sure [01:06] any new business? general problems? PITA branches ? [01:07] nothing from me [01:07] are people doing pre-implemenation calls? [01:07] i haven't seen many p= tags in merges [01:07] good question. [01:07] I WANT MORE! [01:08] I haven't had any requests for them [01:08] or something like that [01:08] I think like reviews, we need to make it mandatory [01:08] kiko asked me what the "p=" bit was when I merged a branch with one ... [01:08] reviewers should be doing one each day at least [01:08] with a special opt-OUT [01:08] FFS [01:08] kiko has been "allergic" to voice calls recently, it seems [01:08] like the trivial merge is an opt out [01:08] voice calls are important for makeing people work together effectively [01:09] I want the launchpad team to have more voice calls, about the code people are working on [01:09] about the features they're working on [01:09] btw what is your asterisk voice quality like ? [01:09] maybe it's a time planning thing [01:09] [I agree with what you are saying and share that desire] [01:10] I think many people like to get various organisational things done in the morning [01:10] the review process suffered when reviewers grabbed their own reviews - which is very much a time management thing [01:10] before getting on with other work [01:10] but that means that guys in the americas won't get calls with guys further east [01:10] how about this... [01:11] get everyone to set aside 1hr a day for such calls [01:11] it won't necessarily be used every day [01:11] but have a more fixed time for it [01:11] by everyone, you mean 'all reviewers' or 'all lp team members' ? [01:11] everyone [01:11] ok [01:11] bjorn and brad should have voice calls [01:11] cprov and malcc should have voice calls [01:12] reviewers and everyone else should have voice calls [01:12] so the idea is that the person you are ringing has a guaranteed time slot [01:12] a 20 minute focussed voice call can be worth a lot [01:12] if you want their time, you just look them up on the world clock [01:12] yeah, something like that [01:12] like we have the staff schedule [01:12] their "open office" hour [01:12] brad and i used to have voice calls, but stopped for some reason. i'll make sure we'll start having them regularly again. [01:12] I think this is a good idea [01:13] SteveA: we have weekly voice calls, since 3 or 4 weeks ago [01:13] cprov: you were having daily ones a while back [01:14] SteveA: can you bring this up in the lp meeting ? [01:14] its in the minuts for this one. [01:14] please someone add it [01:14] I really must get back to this meeting [01:14] I'll add it [01:14] ta [01:14] I want to put your name beside it :) [01:15] reviewers can be proactive [01:15] and tell people that they haven't spoken with them in a while [01:15] and that they have interesting code ideas [01:15] so would like to takl [01:15] yes [01:15] in a sense, reviewers are the condiut of coding knowledge around the company [01:16] I'd like to encourage reviewers to grab people for 20-30 minute talks about the coding they're doing [01:16] SteveA: yes, during some critical time we have more than one call a week, when dsilvers were leaving. Do you think it's worth to document it, I mean, send and email to lp ML with summarized topics discussed in the call ? [01:16] or cool features they're doing [01:16] or talking about the new forms facilities, and how to best use them [01:16] etc. [01:16] cprov: yes, that is a good discipline [01:16] and shows people that you're leading the field on having useful calls [01:17] SteveA: right, will do this week. [01:17] ok, great === SteveA --> meeting [01:17] ok [01:17] anything else ? [01:17] there are two dsilvers branches in needs-reply state [01:18] a 1 month old branch and a 2 month old branch [01:18] ok [01:18] just change them to be malcc [01:18] i.e. nag him [01:18] I assume he isn't going to finish them off, so some decision needs to be made on whether they are to be abandoned or adopted [01:19] I'll email him about them then. [01:19] lifeless: Good call, I'll get those branches off PendingReviews today; we've discussed them with Daniel last week and they're to be abandoned [01:19] ok [01:19] 5 [01:19] (end of meeting [01:19] 4 [01:19] malcc: cool. Could you update PendingReviews page then? [01:19] (counting down [01:19] 3 [01:19] jamesh: Will do [01:19] (really soon now [01:19] 2 [01:19] (it will be over [01:19] 1 [01:19] (it is over [01:20] thanks for coming [01:20] malcc: there is also dsilvers/launchpad-repo/launchpad/bug-47770 -- I suppose that needs to be adopted by someone? [01:22] jamesh: cprov's taken over the bug and marked it fix released, I'll have a poke around and find out if that's just a misunderstanding and we do actually need the code which was in review [01:23] jamesh, malcc: the bug fix itself was merged in one of my branches and released [01:23] cprov: Cool [01:23] I'm not sure about what is inside now === cprov looking [01:26] malcc: a new test for the bug, but I've already done one before committing, do you think it's worth to add this new one ? [01:27] cprov: I'd say, only if it takes a different approach we might want in the code so we can copy it for other tests. Otherwise, one test is the right number :) [01:28] ok, gnight all [01:28] malcc: so, discard it, it's doing exactly what I did inside drq-dist-upgrader.txt. [01:28] I'm off [01:29] cprov: Cool, thanks for double checking [01:29] malcc: np [01:34] danilos: congratulations, your first merges! [01:34] :-P [01:35] carlos: thanks :) [01:35] btw, what's the thing with holidays? I don't even know what are all official holidays in Serbia :) [01:37] danilos: you should know them ;-) [01:37] danilos: you put them on StaffCalendar [01:37] and you don't work those days [01:47] carlos: ha, nice one :) [01:52] how interesting [01:53] the nautilus import causes the gnome cvs to sigbus... [01:53] first time I come across that signal [01:54] Let's do the bus warp again! === ddaa restarts import [01:55] ddaa: lucky you === carlos -> lunch [02:18] stub: ping ? === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === ddaa -> lunch === Zomb [n=eb@x118.rhrk.uni-kl.de] has left #launchpad ["Verlassend"] [02:52] cprov: pong [02:53] stub: I'm facing problem related with DB transaction in one of the soyuz tests, can you help me ? [02:54] perhaps [02:55] stub: fine, DB updates are not visible for external scripts, even after commit() & flush_database_updates(). any clue ? [02:56] The external script must have already opened a connection and started a transaction for that to have happened, or the external script is connecting to a different database. btw. flush_database_updates() should be done before the commit() [02:58] stub: the former would be impossible, because the new item was inserted in the test, it's visible, but not the update on it. the second, maybe, let me check [03:00] stub: aha, fixed ;) I'm a little concerned about the need of these call. Can't we have something like auto-commit for tests ? [03:02] cprov: Then you would not be testing the real behavior. Also, we only want to commit when necessary as a test which doesn't make and commit changes means the next test can reuse the existing database, saving a few seconds. [03:02] Needing flush_database_updates is an open bug though. [03:03] stub: yes, I see your point and yes, I've seen your note on drq-dist-upgrade.txt [03:03] stub: fine by me, thank you for helping me. [03:03] If it is a pita for a particular test, I think it means you need a helper (eg. commit all outstanding changes and run this script) [03:05] stub: good point, It makes sense for most of the soyuz end-to-end tests [03:13] stub: uhm, caches needs to be invalidate as well, Content.get() returns the old instance in this context, how does it sound to you ? [03:14] stub: and what exactly does this error mean ?: [03:14] Exception exceptions.TypeError: "'NoneType' object is not callable" in > ignored [03:20] cprov: garbage collection problems [03:20] cprov: the function the __del__ method is trying to call has been replaced with a reference to "None" [03:22] jamesh: yup, I got more or less the meaning of it, but what can be causing it ? badly handling "transaction" module ? [03:23] morning === Keybuk [n=scott@quest.netsplit.com] has joined #launchpad === bradb [n=bradb@209.217.74.66] has joined #launchpad [03:52] any reviewer up for a trivial review? [03:52] carlos, don't you think it would be worth refactoring the browser code for translation before doing the TranslationReview work? [03:53] carlos, I think you'll end up with a terrible mess if you try to extend that code further.. [03:53] BjornT, sure, [03:53] kiko: I need to finish the form changes as soon as possible [03:53] kiko: so the UI sprint gives us some love there [03:53] about the functionality (browser.py) yes, I will be happy if you give me what you have and finish it [03:54] kiko: https://sodium.ubuntu.com/~andrew/paste/filesBq2tS.html [03:54] I don't have that branch anymore, it bitrotted to death [03:54] kiko: so I should start again? [03:54] kiko: it's a fix for bug 53903 [03:54] Malone bug 53903 in malone "Attached files no longer linked in mails " [Untriaged,In progress] https://launchpad.net/bugs/53903 [03:54] ok, the idea was to use a common parent, right? [03:54] carlos, well, I never got too far there -- the idea was basically to avoid duplication in it. [03:54] carlos, now, two things [03:54] carlos, a) I can write to you a suggested class-and-template structure [03:55] carlos, b) this should be done as a separate branch, because reviewing the two things at once will be crazy [03:55] BjornT, was that a bug, or what? [03:55] kiko: ok [03:55] heh [03:56] BjornT, are there other spots in database/bug that we should be notify()ing but aren't? [03:56] kiko: anyway, I think I remember more or less your initial patch (the idea behind it at least) [03:56] carlos, it had flaws. I'll email you today with a set of comments on how I think they should be refactored. thanks! [03:57] ok [03:57] kiko: thanks to you [03:59] kiko: probably. currently we're not consistent, sometimes we notify outside the db code, sometimes inside. i'm not sure whether there is a reason for those places where we notify outside the db code, though. [03:59] BjornT, those sound like bugs :-( [03:59] BjornT, so did we just not test the fact that we sent email for new attachments? [04:00] kiko: yeah. we did have tests that the notification is correctly generated if there are attachments in the BugDelta. [04:01] BjornT, hmmm. are we not emitting the even twice? [04:01] BjornT, is there a bug # for this change? [04:02] kiko: according to the test i just added, we're emitting it only once. how come you think we do it twice? [04:02] 16:54 < BjornT> kiko: it's a fix for bug 53903 [04:02] Malone bug 53903 in malone "Attached files no longer linked in mails " [Untriaged,In progress] https://launchpad.net/bugs/53903 [04:02] BjornT, well.. [04:02] sorry, didn't see that. [04:06] BjornT, the bug says "no longer". did this regress? or did we never send email if attaching was the only thing that you did? === bradb [n=bradb@209.217.74.66] has joined #launchpad [04:07] kiko: it did regress. i think the view was changed from an AddView to a GeneralFormView, but no event notification was added. [04:08] ah. AddView emits an event notification? [04:08] yeah [04:08] so if the DB class emits an event and the addview does as well.. does that mean two events get emitted? [04:09] yes it does. OTOH, we'll be moving away from SQLObjectAddView to LaunchpadFormView, which doesn't emit any events at all by default. === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad [04:11] BjornT, s/by default// right? I mean, the emission would be done in browser/ code, correct? [04:13] kiko: yeah. what i meant was that we will not have any form class that will automatically emit events, you have to do it yourself, either in browser/ code, or somewhere else. [04:13] that makes you more aware of the events, preventing event duplications. [04:14] BjornT, right. last question: is the test in bugattachments now robust over changes of this type? [04:15] I am confused as to why this test didn't contain attachment notifications [04:15] since the document /is/ called bugattachments.txt :) [04:15] BjornT, I get the feeling there is a functional test we are missing [04:15] BjornT, something that doesn't require TestEventListener() [04:15] but perhaps I am wrong [04:16] kiko: yes, it should prevent similar regressions. it makes sure that adding an attachment via the view class causes a notification to be added in BugNotification. [04:17] kiko: the test that really prevents the regression isn't dependent on TestEventListener. [04:17] ah, ok, I see [04:17] + >>> print latest_notification.message.text_contents [04:17] + ** Attachment added: "blah" [04:17] + http://.../foo.txt [04:17] you query BugNotification [04:17] sorry, missed that [04:17] r=kiko [04:17] thanks === T`Amat [i=justme@dyn216-8-163-241.ADSL.mnsi.net] has joined #launchpad [04:29] kiko [04:30] SteveA, === cprov [n=cprov@monga.dorianet.com.br] has joined #launchpad [04:37] Will Launchpad be eventually able to start sending page data before the page rendering is complete? [04:38] Streaming the page contents in that way, along with moving as much stuff as possible out of https, should do a lot to help the perceived slowness of launchpad. === erdalronahi__ [n=erdal@p5087638B.dip.t-dialin.net] has joined #launchpad [04:49] stub: I'm not sure whether my testing on staging is being slow or it's stalled, are you able to check it? === mholthaus [n=mholthau@71.17.76.83.cust.bluewin.ch] has joined #launchpad [05:01] carlos: what testing? [05:01] the edgy opening [05:01] I'm testing my latest changes [05:06]