[01:10] <sabdfl> hey lifeless
[01:10] <sabdfl> lifeless: do you know what time the staging update happens?
[01:37] <lifeless> sabdfl: not offhand
[01:38] <lifeless> sabdfl: sorry
[01:38] <sabdfl> ok thanks
[01:38] <sabdfl> night all
[01:38] <lifeless> I'm pretty sure stub has mailed that to the lp list
[01:38] <lifeless> gnight
[03:22] <jamesh> good morning
[03:23] <spiv> jamesh: morning.
[03:23] <spiv> jamesh: your laptop made it home ok?
[03:23] <jamesh> yeah
[03:23] <jamesh> seems to be working fine
[03:25] <jamesh> how's the smart server stuff going?
[03:26] <spiv> Slowly, but making progress.  There are quite a few tests that assume a local transport, and other little issues.
[04:45] <WebMaven> what's smart server?
[04:58] <spiv> WebMaven: http://bazaar-vcs.org/SmartServer
[04:58] <jamesh> WebMaven: something to speed up bzr's network performance
[04:59] <jamesh> 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] <jamesh> 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] <jamesh> (hopefully)
[05:20] <imbrandon> hrm any LP admins arround i can poke for a second
[05:23] <imbrandon> 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 <lp-id>@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] <imbrandon> can someone poke the dns to refresh or at very leaste update the alias file to point to my new contact email
[05:24] <imbrandon> heh
[05:30] <jamesh> 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] <jamesh> morning stub
[05:30] <imbrandon> ahh jamesh thanks , probably riddell he who set me up the first time
[05:30] <imbrandon> thanks
[05:30] <ausimage> 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] <Ubugtu> Malone bug 56282 in lyx "Edgy Dependency Issue" [Untriaged,Unconfirmed]  https://launchpad.net/bugs/56282
[05:31] <stub> Morning
[05:31] <imbrandon> ausimage: try in #ubuntu-motu for info about getting new packages in edgy
[05:31] <jamesh> stub: no problems with your luggage?
[05:31] <ausimage> K crimsun sent me here...
[05:32] <stub> imbrandon: elmo or possibly Znarl or Spads are the only ones who can poke the email address aliases.
[05:32] <stub> jamesh: Thankfully no.
[05:32] <imbrandon> stub: ahh ok, since i'm not arround #launchpad that much whats the "normal" times they are awake/alive ?
[05:33] <stub> 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] <jamesh> 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] <jamesh> yeah.  I think they were under special instructions everywhere :)
[05:34] <stub> 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] <imbrandon> stub: good idea thanks again for yall time for something trivial ;)
[05:34] <stub> 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] <jamesh> 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] <jamesh> stub: by the time I'd checked in, the passport control had gone out the door of the terminal ...
[05:36] <stub> Hmm... I went straight to checking, then onto the security queue which was like something out of a terry gilliam movie
[05:36] <stub> (passport queue)
[05:36] <stub> 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] <imbrandon> stub: one last dumbish question , file it against the LP product ? or does it realy matter ......
[05:37] <stub> Thankfully, after going the entire length of terminal 3, through a lengthy set of passages, it eventually stopped in the multistory carpark.
[05:37] <crimsun> 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] <Ubugtu> Malone bug 56282 in lyx "Edgy Dependency Issue" [Untriaged,Unconfirmed]  https://launchpad.net/bugs/56282
[05:37] <stub> imbrandon: Yes
[05:37] <jamesh> 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] <imbrandon> stub: ok thanks
[05:38] <stub> 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] <stub> 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] <stub> (Not that anyone would be smuggling drugs out of the UK)
[05:40] <jamesh> crimsun: the guys who could answer your question won't be up for a while yet
[05:40] <crimsun> jamesh: np, thanks.
[05:42] <jamesh> I got my "don't destroy this person's luggage" silver frequent flyer luggage tags in the mail while I was away
[05:49] <lifeless> woo
[06:05] <lifeless> stub: sounds traumatic
[06:05] <lifeless> stub: and we want a conference in the US after this ?!
[06:06] <stub> I doubt it as they are even more paranoid than the UK. I'll stick that wiki page up (already drafted)
[06:28] <lifeless> stub: now we need some publicity
[06:28] <lifeless> ;)
[06:40] <jamesh> stub: nice page title
[06:49] <jamesh> 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] <lifeless> yes
[06:49] <lifeless> I'd love someone else to do that, its not high on my priority list
[06:49] <lifeless> - because bzr needs much luv
[06:50] <jamesh> I saw the performance comparison page for bzr 0.9
[06:50] <jamesh> congratulations
[06:50] <lifeless> thanks
[06:50] <lifeless> still a lot to do though
[06:51] <lifeless> has anyone done work to teach oprofile how to get python stack frame data ?
[06:52] <lifeless> or any vm based machine for that matter (mono etc)
[06:52] <spiv> Hmm, not that I know of.
[06:53] <lifeless> I got to grips with it in the weekend
[06:53] <lifeless> its really quite nice
[06:53] <jamesh> spiv: did you see the review of your short posix-shell-happy branch?
[06:54] <spiv> jamesh: yeah, I did.
[06:54] <spiv> jamesh: that seems like a nice solution.
[06:57] <jamesh> spiv: any particular reason you wanted to build launchpad with dash? :)
[07:00] <spiv> jamesh: it is (was?) the default shell on edgy, apparently.
[07:00] <spiv> sivang reported the problem.
[07:00] <spiv> 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] <jamesh> I suppose having a basic bourne shell as /bin/sh isn't that bad an idea :)
[07:04] <spiv> 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] <spiv> 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] <lifeless> dash is definately much faster
[07:13] <jamesh> faster startup or faster at running scripts or both?
[07:16] <lifeless> both
[07:16] <lifeless> its less functional though
[07:22] <jamesh> if you call /bin/sh and expect features of bash, your code is broken
[07:22] <lifeless> right
[08:22] <stub> spiv: Does this fix under edgy database/schema/Makefile too? Mark emailed me earlier about it
[08:25] <jamesh> stub: sounds like it.
[08:31] <spiv> stub: that's the Makefile it changes, yep.
[08:35] <jamesh> spiv: so you'd make sabdfl happy by landing it :)
[08:49] <sabdfl> thanks spivomatic!
[08:53] <sabdfl> stub: for future reference, what time does the staging update happen?
[08:54] <stub> after the daily backup is done and copied to the staging server.
[08:55] <stub> About 1:20 UTC at the moment, give or take 10 mins
[08:55] <stub> erm... BST.
[09:01] <sabdfl> ok, thanks
[09:25] <carlos> morning
[09:26] <carlos> stub: hi, around?
[10:22] <stub> carlos: ping
[10:22] <carlos> stub: hi
[10:22] <carlos> stub: what's the status of the migration ?
[10:23] <stub> 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] <carlos> hmmm
[10:23] <carlos> my fault?
[10:24] <carlos> stub: bug number ?
[10:27] <stub> Hmm... I have the outgoing email, but it looks like Malone dropped it
[10:31] <carlos> stub: what's it about?
[10:42] <SteveA> lifeless: ping
[10:58] <SteveA> lifeless: ping
[10:58] <lifeless> pong
[10:58] <SteveA> hi
[11:08] <lifeless> jamesh: SteveA: tickcount is packaged and should be in NEW now
[11:08] <lifeless> I'll do an ITP for debian sometime this week
[11:09] <jamesh> lifeless: cool.
[11:09] <lifeless> sources are http://people.ubuntu.com/~robertc/tickcount/ if you want to fiddle
[11:09] <lifeless> edgy and dapper are quite different for python now - this is packaged for edgy and beyond
[11:11] <danilos> stub: ping
[11:11] <SteveA> lifeless: way cool.  we need it for both dapper and edgy.
[11:11] <danilos> carlos: edgy migration issues (by stub): https://launchpad.net/bugs/56314
[11:11] <lifeless> 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] <carlos> danilos: I know, I already talked with him about it
[11:12] <SteveA> because the whole point is to deploy it in the DC.
[11:12] <carlos> I'm fixing it right now
[11:12] <danilos> carlos: ok :)
[11:12] <SteveA> lifeless: a binary for dapper is okay.
[11:12] <carlos> danilos: sorry for not told you about it
[11:12] <danilos> carlos: np, I've just got the email about it
[11:12] <SteveA> lifeless: so I can just ask the admins and launchpad developers to install it
[11:12] <lifeless> I'll talk to the sysadmins about their preference then
[11:12] <SteveA> thanks lifeless 
[11:12] <lifeless> they build their own anyway
[11:12] <lifeless> so its really whats easiest for them
[11:13] <SteveA> also, there is some interest from the support team on taking on small packaging tasks
[11:13] <SteveA> so, if you're already fully booked, see if you can pass it along to etienne
[11:14] <ddaa> Good morning
[11:15] <lifeless> I'm happy to maintain tickcount in ubuntu and debian indefinately
[11:15] <danilos> stub: have you had a chance to look at my bug 30602 mail?
[11:15] <Ubugtu> 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] <lifeless> it keeps my hand in to have some packages to care for
[11:16] <SteveA> lifeless: fine with me
[11:16] <lifeless> 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
[11:17] <ddaa> 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 :)
[11:28] <carlos> danilos: I found the problem and It's fixed. I'm going to test it on staging now
[11:28] <danilos> carlos: great, hopefully we'll get farther away this time
[11:28] <danilos> carlos: do you have a test for the problem as well?
[11:29] <carlos> It will require sampledata changes so I'm working on it
[11:56] <ddaa> lifeless: SteveA: mpool: jamesh: spiv: meeting in 4 mins
[12:01] <jamesh> ddaa: on #launchpad-meeting?
[12:02] <ddaa> Yes, as usual
[12:02] <ddaa> mpool: SteveA: please report to astrometrics^W #launchpad-meeting
[12:07] <carlos> 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] <carlos> well, and Stuart is not around to fix it...
[12:09] <carlos> lifeless: it's unlocked now
[12:09] <carlos> so don't worry about it. Thanks
[12:47] <lifeless> reviewer meeting in 13
[12:47] <SteveA> lifeless: can you turn off the regex [r=who]  thing for the launchpad/ui-one-zero branch please?
[12:48] <lifeless> sure
[12:48] <SteveA> tell me when you have and I'll resubmit my merge
[12:49] <lifeless> done
[12:52] <SteveA> ta
[01:00] <lifeless>  reviewer meeting time
[01:00] <lifeless> whos here ?
[01:00] <spiv> me
[01:01] <jamesh> me
[01:01] <lifeless>  * Next meeting
[01:01] <lifeless>  * Queue status.
[01:01] <BjornT> me
[01:01] <SteveA> hi
[01:02] <lifeless> cool
[01:02] <lifeless> 10 items in the queue
[01:03] <lifeless> 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] <SteveA> not really paying attention, as i'm in meetings
[01:03] <lifeless> SteveA: thats fine
[01:03] <lifeless> SteveA: you're optional anyhow ;)
[01:03] <lifeless> kiko-fud: your branch is reallly getting old - the tt-search branch
[01:04] <lifeless> spiv, you have  abrnach that is getting a little old
[01:04] <lifeless> other than that its all looking fine to me
[01:05] <lifeless> oh, next meeting, this time - is that ok ?
[01:05] <jamesh> sure.
[01:05] <BjornT> sure
[01:06] <lifeless> any new business? general problems? PITA branches ?
[01:07] <BjornT> nothing from me
[01:07] <SteveA> are people doing pre-implemenation calls?
[01:07] <SteveA> i haven't seen many p= tags in merges
[01:07] <lifeless> good question.
[01:07] <SteveA> I WANT MORE!
[01:08] <lifeless> I haven't had any requests for them
[01:08] <SteveA> or something like that
[01:08] <lifeless> I think like reviews, we need to make it mandatory
[01:08] <jamesh> kiko asked me what the "p=" bit was when I merged a branch with one ...
[01:08] <SteveA> reviewers should be doing one each day at least
[01:08] <lifeless> with a special opt-OUT
[01:08] <SteveA> FFS
[01:08] <SteveA> kiko has been "allergic" to voice calls recently, it seems
[01:08] <lifeless> like the trivial merge is an opt out
[01:08] <SteveA> voice calls are important for makeing people work together effectively
[01:09] <SteveA> I want the launchpad team to have more voice calls, about the code people are working on
[01:09] <SteveA> about the features they're working on
[01:09] <lifeless> btw what is your asterisk voice quality like ?
[01:09] <SteveA> maybe it's a time planning thing
[01:09] <lifeless> [I agree with what you are saying and share that desire] 
[01:10] <SteveA> I think many people like to get various organisational things done in the morning
[01:10] <lifeless> the review process suffered when reviewers grabbed their own reviews - which is very much a time management thing
[01:10] <SteveA> before getting on with other work
[01:10] <SteveA> but that means that guys in the americas won't get calls with guys further east
[01:10] <SteveA> how about this...
[01:11] <SteveA> get everyone to set aside 1hr a day for such calls
[01:11] <SteveA> it won't necessarily be used every day
[01:11] <SteveA> but have a more fixed time for it
[01:11] <lifeless> by everyone, you mean 'all reviewers' or 'all lp team members' ?
[01:11] <SteveA> everyone
[01:11] <lifeless> ok
[01:11] <SteveA> bjorn and brad should have voice calls
[01:11] <SteveA> cprov and malcc should have voice calls
[01:12] <SteveA> reviewers and everyone else should have voice calls
[01:12] <lifeless> so the idea is that the person you are ringing has a guaranteed time slot
[01:12] <SteveA> a 20 minute focussed voice call can be worth a lot
[01:12] <lifeless> if you want their time, you just look them up on the world clock
[01:12] <SteveA> yeah, something like that
[01:12] <lifeless> like we have the staff schedule
[01:12] <SteveA> their "open office" hour
[01:12] <BjornT> 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] <lifeless> I think this is a good idea
[01:13] <cprov> SteveA: we have weekly voice calls, since 3 or 4 weeks ago
[01:13] <SteveA> cprov: you were having daily ones a while back
[01:14] <lifeless> SteveA: can you bring this up in the lp meeting ?
[01:14] <lifeless> its in the minuts for this one.
[01:14] <SteveA> please someone add it
[01:14] <SteveA> I really must get back to this meeting
[01:14] <lifeless> I'll add it
[01:14] <SteveA> ta
[01:14] <lifeless> I want to put your name beside it :)
[01:15] <SteveA> reviewers can be proactive
[01:15] <SteveA> and tell people that they haven't spoken with them in a while
[01:15] <SteveA> and that they have interesting code ideas
[01:15] <SteveA> so would like to takl
[01:15] <lifeless> yes
[01:15] <SteveA> in a sense, reviewers are the condiut of coding knowledge around the company
[01:16] <SteveA> I'd like to encourage reviewers to grab people for 20-30 minute talks about the coding they're doing
[01:16] <cprov> 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] <SteveA> or cool features they're doing
[01:16] <SteveA> or talking about the new forms facilities, and how to best use them
[01:16] <SteveA> etc.
[01:16] <SteveA> cprov: yes, that is a good discipline
[01:16] <SteveA> and shows people that you're leading the field on having useful calls
[01:17] <cprov> SteveA: right, will do this week.
[01:17] <SteveA> ok, great
[01:17] <lifeless> ok
[01:17] <lifeless> anything else ?
[01:17] <jamesh> there are two dsilvers branches in needs-reply state
[01:18] <jamesh> a 1 month old branch and a 2 month old branch
[01:18] <lifeless> ok
[01:18] <lifeless> just change them to be malcc
[01:18] <lifeless> i.e. nag him
[01:18] <jamesh> 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] <jamesh> I'll email him about them then.
[01:19] <malcc> 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] <lifeless> ok
[01:19] <lifeless> 5
[01:19] <lifeless> (end of meeting
[01:19] <lifeless> 4
[01:19] <jamesh> malcc: cool.  Could you update PendingReviews page then?
[01:19] <lifeless> (counting down
[01:19] <lifeless> 3
[01:19] <malcc> jamesh: Will do
[01:19] <lifeless> (really soon now
[01:19] <lifeless> 2
[01:19] <lifeless> (it will be over
[01:19] <lifeless> 1
[01:19] <lifeless> (it is over
[01:20] <lifeless> thanks for coming
[01:20] <jamesh> malcc: there is also dsilvers/launchpad-repo/launchpad/bug-47770 -- I suppose that needs to be adopted by someone?
[01:22] <malcc> 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] <cprov> jamesh, malcc: the bug fix itself was merged in one of my branches and released
[01:23] <malcc> cprov: Cool
[01:23] <cprov> I'm not sure about what is inside now 
[01:26] <cprov> 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] <malcc> 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] <lifeless> ok, gnight all
[01:28] <cprov> malcc: so, discard it, it's doing exactly what I did inside drq-dist-upgrader.txt. 
[01:28] <lifeless> I'm off
[01:29] <malcc> cprov: Cool, thanks for double checking
[01:29] <cprov> malcc: np
[01:34] <carlos> danilos: congratulations, your first merges!
[01:34] <carlos> :-P
[01:35] <danilos> carlos: thanks :)
[01:35] <danilos> btw, what's the thing with holidays? I don't even know what are all official holidays in Serbia :)
[01:37] <carlos> danilos: you should know them ;-)
[01:37] <carlos> danilos: you put them on StaffCalendar
[01:37] <carlos> and you don't work those days
[01:47] <danilos> carlos: ha, nice one :)
[01:52] <ddaa> how interesting
[01:53] <ddaa> the nautilus import causes the gnome cvs to sigbus...
[01:53] <ddaa> first time I come across that signal
[01:54] <ddaa> Let's do the bus warp again!
[01:55] <LarstiQ> ddaa: lucky you
[02:18] <cprov> stub: ping ?
[02:52] <stub> cprov: pong
[02:53] <cprov> stub: I'm facing problem related with DB transaction in one of the soyuz tests, can you help me ?
[02:54] <stub> perhaps
[02:55] <cprov> stub: fine, DB updates are not visible for external scripts, even after commit() & flush_database_updates(). any clue ?
[02:56] <stub> 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] <cprov> 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] <cprov> 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] <stub> 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] <stub> Needing flush_database_updates is an open bug though.
[03:03] <cprov> stub: yes, I see your point and yes, I've seen your note on drq-dist-upgrade.txt
[03:03] <cprov> stub: fine by me, thank you for helping me.
[03:03] <stub> 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] <cprov> stub: good point, It makes sense for most of the soyuz end-to-end tests
[03:13] <cprov> 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] <cprov> stub: and what exactly does this error mean ?:
[03:14] <cprov> Exception exceptions.TypeError: "'NoneType' object is not callable" in <bound method Transaction.__del__ of <sqlobject.dbconnection.Transaction object at 0xb520d7ec>> ignored
[03:20] <jamesh> cprov: garbage collection problems
[03:20] <jamesh> cprov: the function the __del__ method is trying to call has been replaced with a reference to "None"
[03:22] <cprov> jamesh: yup, I got more or less the meaning of it, but what can be causing it ? badly handling "transaction" module ?
[03:23] <kiko-fud> morning
[03:52] <BjornT> any reviewer up for a trivial review?
[03:52] <kiko> carlos, don't you think it would be worth refactoring the browser code for translation before doing the TranslationReview work?
[03:53] <kiko> carlos, I think you'll end up with a terrible mess if you try to extend that code further..
[03:53] <kiko> BjornT, sure,
[03:53] <carlos> kiko: I need to finish the form changes as soon as possible
[03:53] <carlos> kiko: so the UI sprint gives us some love there
[03:53] <carlos> about the functionality (browser.py) yes, I will be happy if you give me what you have and finish it
[03:54] <BjornT> kiko: https://sodium.ubuntu.com/~andrew/paste/filesBq2tS.html
[03:54] <kiko> I don't have that branch anymore, it bitrotted to death
[03:54] <carlos> kiko: so I should start again?
[03:54] <BjornT> kiko: it's a fix for bug 53903
[03:54] <Ubugtu> Malone bug 53903 in malone "Attached files no longer linked in mails " [Untriaged,In progress]  https://launchpad.net/bugs/53903
[03:54] <carlos> ok, the idea was to use a common parent, right?
[03:54] <kiko> carlos, well, I never got too far there -- the idea was basically to avoid duplication in it.
[03:54] <kiko> carlos, now, two things
[03:54] <kiko> carlos, a) I can write to you a suggested class-and-template structure 
[03:55] <kiko> carlos, b) this should be done as a separate branch, because reviewing the two things at once will be crazy
[03:55] <kiko> BjornT, was that a bug, or what?
[03:55] <carlos> kiko: ok
[03:55] <kiko> heh
[03:56] <kiko> BjornT, are there other spots in database/bug that we should be notify()ing but aren't?
[03:56] <carlos> kiko: anyway, I think I remember more or less your initial patch (the idea behind it at least)
[03:56] <kiko> 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] <carlos> ok
[03:57] <carlos> kiko: thanks to you
[03:59] <BjornT> 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] <kiko> BjornT, those sound like bugs :-(
[03:59] <kiko> BjornT, so did we just not test the fact that  we sent email for new attachments?
[04:00] <BjornT> kiko: yeah. we did have tests that the notification is correctly generated if there are attachments in the BugDelta.
[04:01] <kiko> BjornT, hmmm. are we not emitting the even twice? 
[04:01] <kiko> BjornT, is there a bug # for this change?
[04:02] <BjornT> kiko: according to the test i just added, we're emitting it only once. how come you think we do it twice?
[04:02] <BjornT> 16:54 < BjornT> kiko: it's a fix for bug 53903
[04:02] <Ubugtu> Malone bug 53903 in malone "Attached files no longer linked in mails " [Untriaged,In progress]  https://launchpad.net/bugs/53903
[04:02] <kiko> BjornT, well.. 
[04:02] <kiko> sorry, didn't see that.
[04:06] <kiko> BjornT, the bug says "no longer". did this regress? or did we never send email if attaching was the only thing that you did?
[04:07] <BjornT> kiko: it did regress. i think the view was changed from an AddView to a GeneralFormView, but no event notification was added.
[04:08] <kiko> ah. AddView emits an event notification?
[04:08] <BjornT> yeah
[04:08] <kiko> so if the DB class emits an event and the addview does as well.. does that mean two events get emitted?
[04:09] <BjornT> yes it does. OTOH, we'll be moving away from SQLObjectAddView to LaunchpadFormView, which doesn't emit any events at all by default.
[04:11] <kiko> BjornT, s/by default// right? I mean, the emission would be done in browser/ code, correct?
[04:13] <BjornT> 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] <BjornT> that makes you more aware of the events, preventing event duplications.
[04:14] <kiko> BjornT, right. last question: is the test in bugattachments now robust over changes of this type?
[04:15] <kiko> I am confused as to why this test didn't contain attachment notifications
[04:15] <kiko> since the document /is/ called bugattachments.txt :)
[04:15] <kiko> BjornT, I get the feeling there is a functional test we are missing
[04:15] <kiko> BjornT, something that doesn't require TestEventListener()
[04:15] <kiko> but perhaps I am wrong
[04:16] <BjornT> 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] <BjornT> kiko: the test that really prevents the regression isn't dependent on TestEventListener.
[04:17] <kiko> ah, ok, I see
[04:17] <BjornT> +    >>> print latest_notification.message.text_contents
[04:17] <BjornT> +    ** Attachment added: "blah"
[04:17] <BjornT> +       http://.../foo.txt
[04:17] <kiko> you query BugNotification
[04:17] <kiko> sorry, missed that
[04:17] <kiko> r=kiko
[04:17] <BjornT> thanks
[04:29] <SteveA> kiko
[04:30] <kiko> SteveA,
[04:37] <ddaa> Will Launchpad be eventually able to start sending page data before the page rendering is complete?
[04:38] <ddaa> 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.
[04:49] <carlos> stub: I'm not sure whether my testing on staging is being slow or it's stalled, are you able to check it?
[05:01] <stub> carlos: what testing?
[05:01] <carlos> the edgy opening
[05:01] <carlos> I'm testing my latest changes
[05:06] <stub> carlos: disks are being thrashed. Not sure what is doing it - might be you.
[05:06] <carlos> should I kill my process?
[05:09] <stub> It is your script that is thrashing it as far as I can tell. I'd just leave it running. If it doesn't complete, I can test it on Carbon tomorrow.
[05:13] <stub> carlos: From your account on asuka, please try 'psql -d launchpad_test -h carbon -U rosettaadmin'
[05:14] <carlos> psql: FATAL:  Ident authentication failed for user "rosettaadmin"
[05:14] <carlos> stub: I usually connect from the launchpad account on asuka
[05:14] <carlos> using sudo
[05:15] <stub> You can test the script quickly against that db, but you won't be able to see the results so I wouldn't kill the staging run just yet.
[05:15] <stub> My bad - typo. Try again.
[05:15] <stub> Should work from either 'carlos' or 'launchpad' accounts.
[05:15] <stub> carlos: ^^^
[05:16] <carlos> stub: I'm connected now
[05:16] <carlos> ok, so I should get another tree on asuka to connect to that database, right?
[05:16] <stub> ok. Do what you want with that db. Don't run more than one script at a time though or you might affect demo.launchpad.net
[05:17] <stub> carlos: You can use the same tree. You just need to duplicate the staging/* config
[05:17] <stub> And change the 'dbhost'
[05:22] <carlos> stub: ok, thanks
[05:23] <milosz> hey guys, i'm having problems importing new translation templates
[05:23] <milosz> i tried adding them in twice now (over the coure of last week) and they still haven't apeared yet
[05:23] <carlos> milosz: hi, give me just one minute and I will be all yours
[05:23] <carlos> BjornT: about your email
[05:24] <carlos> BjornT: I'm not 'complaining' about two emails, but that the first one already says that I'm the assignee of that bug
[05:25] <carlos> and the second email says that I was not until that second email
[05:26] <carlos> milosz: hi, what URL are you using to do the upload ?
[05:27] <BjornT> carlos: well, i'd say that's part of bug 51046. you shouldn't get a 'public bug reported' email, you should get a mail that isn't so confusing. 
[05:27] <Ubugtu> Malone bug 51046 in malone "The newbug-style email a new bug contact receives on product/package reassignment is confusing" [Untriaged,Unconfirmed]  https://launchpad.net/bugs/51046
[05:27] <kiko> oh
[05:27] <carlos> ok
[05:27] <BjornT> carlos:  bug 41063 is also somewhat related
[05:28] <Ubugtu> Malone bug 41063 in malone "Mail notification of bug creation includes things that haven't happened yet" [Medium,Confirmed]  https://launchpad.net/bugs/41063
[05:28] <carlos> BjornT: yeah, that one sounds more like what I was trying to point at
[05:28] <kiko> BjornT, is bug 50906 a dupe of that one then?
[05:28] <Ubugtu> Malone bug 50906 in malone "Malone sent me a copy of a bug report two days after it was reported" [Untriaged,Confirmed]  https://launchpad.net/bugs/50906
[05:29] <carlos> well that one is about being late
[05:29] <carlos> we are talking about giving future actions
[05:29] <kiko> carlos, no, read the description.
[05:30] <BjornT> kiko: yeah, it's a dupe.
[05:30] <carlos> for me 'two days after...'  is being late, isn't it ?
[05:30] <kiko> carlos, no, read the description.
[05:30] <carlos> is the word 'copy' the key here ?
[05:30] <carlos> ;-)
[05:30] <kiko> yes
[05:30] <kiko> well
[05:31] <kiko> the summary is misleading
[05:31] <kiko> but the description is clear
[05:31] <carlos> I got that bug too
[05:32] <milosz> carls i just go to my project (drapes) -> translations -> template -> upload template
[05:33] <carlos> milosz: I see, it's a new upload request
[05:33] <carlos> milosz: It requires manual review the first time you do the upload
[05:33] <carlos> jordi: Could you take a look? ^^^
[05:37] <milosz> well i uploaded the orginial template before
[05:37] <milosz> this is an updated one with new strings
[05:39] <kiko> argh, stub's gone
[05:39] <milosz> and it tells me to look throught the import queue but the import queue is long and there is no way to search it
[05:42] <kiko> carlos, danilos: please don't forget my email requesting that information for today!
[05:43] <carlos> kiko: don't worry, I have most of it done
[05:43] <carlos> just waiting for some testing to send you it
[05:43] <kiko> thanks, most appreciated
[05:43] <danilos> kiko: sure, though I got in right in the middle of edgy migration :)
[05:43] <danilos> carlos: if you need any help, just let me know
[05:47] <milosz> carlos: what do i need to do?
[05:47] <carlos> milosz: just one minute, phone...
[05:54] <Sp4rKy_> please when start edgy translation ?
[05:54] <milosz> carlos: okay, i really appereciate the help
[05:56] <carlos> milosz: I'm back
[05:56] <carlos> milosz: I will approve now your files
[05:56] <carlos> milosz: but that URL should be used only when you do the initial import
[05:56] <carlos> next time use https://launchpad.net/products/drapes/trunk/+pots/drapes/+upload
[05:57] <carlos> milosz: that one will get your .pot and .po files automatically (if the .po files use the language code as its filename)
[05:57] <carlos> otherwise you need an admin to review your uploads
[05:57] <Sp4rKy_> carlos, please when start edgy translation ?
[05:57] <carlos> Sp4rKy_: we are working on it atm testing latest details to open it based on what we have in dapper
[05:58] <milosz> carlos: okay, i didn't find that information anywhere
[05:58] <carlos> kiko: when do you plan to send the status email about edgy, tomorrow?
[05:58] <carlos> milosz: ok, I will note that to jordi so we try to improve the documentation about that.
[06:00] <milosz> maybe you should have it automaticaly update the package tempates if you click it again, and you are the project owner?
[06:01] <carlos> milosz: we support more than one template for a given product
[06:01] <carlos> so we need to know which one should get the upload
[06:02] <carlos> milosz: it's approved now
[06:03] <carlos> Sp4rKy_: please, just wait a couple of days and we will give you much more details of its status, but the initial plan is to open it with next production update this week
[06:04] <Sp4rKy_> carlos, k thx
[06:07] <mpt> Goooooooooooooooooooooooooooooood afternoon Launchpadders!
[06:07] <milosz> carlos: thx
[06:07] <malcc> I'm not sure the afternoon has been quite *that* good
[06:07] <carlos> np
[06:09] <ieskantis_kazko> hi
[06:16] <kiko> BjornT, have time for a quick review?
[06:22] <BjornT> kiko: sure
[06:26] <kiko> BjornT, https://sodium.ubuntu.com/~andrew/paste/filehFrYUL.html
[06:27] <kiko> BjornT, it always hides comment zero and offers a link to it when the description has changed
[06:28] <kiko> BjornT, I don't know what tests I need to update but I will as soon as make check will return and then I'll add explicit checks for this.
[06:30] <neutrinomass> I've been having some problems lately with adding upstream tasks to Ubuntu bugs. For example bug 2740 - when adding an upstream task to the gnome bugzilla I get an invalid value in the product field . Am I doing something wrong ?
[06:30] <Ubugtu> Malone bug 2740 in gnome-pim "gnomecal crashes in breezy" [Medium,Unconfirmed]  https://launchpad.net/bugs/2740
[06:31] <BjornT> kiko: that 'assert comments > 0' doesn't look like it does the right thing.
[06:31] <kiko> yeah
[06:31] <kiko> good point
[06:31] <kiko>         assert len(comments) > 0, "A bug should have at least one comment."
[06:31] <kiko> what's wrong with me today, sigh
[06:31] <BjornT> kiko: do we have problems with duplicated comments? is it common?
[06:32] <seb128> neutrinomass: what do you enter to that field?
[06:32] <neutrinomass> seb128: I tried both "gnomecal" and "gnome-pim" and got the same error with both
[06:32] <kiko> BjornT, yeah, it's fairly common.
[06:32] <seb128> neutrinomass: maybe there is no such upstream product listed on launchpad?
[06:32] <kiko> BjornT, I saw it in a number of ubuntu bugs when researching last week
[06:33] <seb128> neutrinomass: products need to be created, that's the case for most of the GNOME desktop but not everything in the world
[06:33] <neutrinomass> seb128: Likely - I'm not exactly sure how the system works.... should this be reported somewhere ?
[06:34] <kiko> BjornT, we could avoid the comments being submitted, but that's a lot more work than omitting them during output.
[06:34] <BjornT> kiko: well, i know that we had some duplicated comments when the bug page was handling the comment adding. now that a separate page does that, we shouldn't add duplicate comments any more.
[06:34] <seb128> kiko: are users supposed to create upstream products? or is a team doing that? or is that something for upstream to ask?
[06:34] <neutrinomass> Indeed - no gnome-pim and no gnomecal exist in launchpad 
[06:34] <kiko> seb128, users are supposed to create products, yes. they can later reassign them.
[06:35] <seb128> kiko: do you have the URL for that handy? :)
[06:35] <kiko> BjornT, yeah. I don't think it hurts to have that code there, though
[06:35] <kiko> seb128, /products/+add
[06:35] <seb128> thank you
[06:35] <kiko> and product/foo/+reassign
[06:35] <neutrinomass> Isn't it  https://launchpad.net/products/+new ?
[06:35] <kiko> or something like that. :)
[06:35] <seb128> yeah, looks the right place
[06:35] <seb128> it was easier to find that I thought :p
[06:35] <neutrinomass> So I just add any products missing when I come across them ?
[06:36] <kiko> BjornT, the user can still submit, stop, submit again, though (click twice on button, etc)
[06:36] <seb128> neutrinomass: feel free yep ;)
[06:36] <neutrinomass> seb128, kiko: Thanks :)
[06:36] <seb128> np, thank you for your work ;)
[06:37] <neutrinomass> Last thing: I add the "product" or the "component" ?
[06:38] <BjornT> kiko: ok, the code looks good. as for tests, i'd like a test for the duplicate comment handling in bug-pages.txt. you should also add a pagetest (don't know where), which checks that the link to the original comment is there, and ensures that the link isn't broken.
[06:38] <kiko> BjornT, I'll add those.
[06:38] <BjornT> kiko: cool, r=me after that
[06:38] <kiko> mmm, will need to add some sampledata too
[06:38] <kiko> okay thanks
[06:40] <milosz> carlos: i uploaded a even newer pot + update po files, and it still says in the queue need review, and that's using the url you gave me
[06:41] <carlos> danilos: could you join #ubuntu-meeting, please ?
[06:41] <carlos> milosz: there is a delay
[06:41] <danilos> carlos: sure
[06:41] <carlos> give it a couple of hours and if it's not imported, ping me, please
[06:47] <neutrinomass> seb128_ : Actually, I'm not sure I should add it after all. It's on the list of "deprecated" products ....
[06:47] <seb128_> neutrinomass: deprecated from where?
[06:49] <neutrinomass> seb128_: http://bugzilla.gnome.org/browse.cgi . See the products list... its under "deprecated" and the homepage http://www.gnome.org/gnome-office/gnome-pim.shtml reveals as much... 
[06:49] <seb128_> neutrinomass: right, maybe no need to bother opening upstream tasks then
[06:50] <neutrinomass> seb128_ : Ok... thanks again
[06:50] <seb128_> np
[06:59] <milosz> carlos: how big of a delay is it?
[06:59] <carlos> milosz: it usually is fast
[07:00] <carlos> but the queue has a bunch of entries for Ubuntu, so it takes a bit more time now
[07:23] <mpt> carlos, has jordi been around recently?
[07:23] <carlos> mpt: he's on vacations until Wednesday
[07:23] <mpt> There are community things that need doing
[07:23] <mpt> ok
[07:23] <mpt> I'll ping him then
[08:33] <kiko> BjornT, I'm finding that my bug-pages test is now randomly failing. eek
[08:34] <kiko> hmmm
[08:34] <kiko> could it be because I'm not committing the transactions..
[08:35] <kiko> the ordering is by datecreated, after all
[08:35] <kiko> yeah
[08:36] <kiko> that was it
[08:36] <kiko> how weird.
[09:04] <danilout> carlos: ping
[09:19] <carlos> danilout: pong
[09:20] <kiko> BjornT, ping?
[09:20] <kiko> or bradb
[09:20] <kiko> or SteveA 
[09:20] <kiko> or jamesh 
[09:20] <bradb> pong
[09:21] <kiko> bradb, so I want to validate/process the data entered for the remote bug field
[09:21] <kiko> bradb, removing, for instance, leading hashes
[09:22] <kiko> bradb, and allowing URLs to be entered
[09:22] <kiko> and then chopping them up accordingly
[09:22] <kiko> bradb, where should I do that, though?
[09:22] <kiko> should I use a validator or a widget?
[09:23] <BjornT> kiko: a widget. look at StrippedTextWidget for an example.
[09:23] <bradb> kiko: I /think/ it might be nice if you can do it inside the widget, so that calling getInputValue returns only the value that will get stored in the db.
[09:23] <kiko> BjornT, does the widget have access to the context? in this specific case, to the bugtracker we're using?
[09:24] <BjornT> kiko: yeah, via self.context.context. self.context is the field.
[09:25] <kiko> BjornT, even if the watch hasn't been created yet? 
[09:28] <BjornT> kiko: well, it depends on where you want to add this. in BugTaskBugWatchWidget, you can get the bugtracker using self.bugtracker_widget.getInputValue()
[09:29] <kiko> BjornT, hmmm. I wish this worked everywhere. :-/
[09:34] <BjornT> kiko: it would be possible to create a new BugWatchWidget, which would make it easier making it work everywhere. but it might be more work than it's worth...
[09:36] <BjornT> kiko: basically that widget would consist of a bugtracker widget, and a remote bug widget, so it's actually not that hard to do. it's adapting the forms/widgets to use it that is the most work.
[09:36] <kiko> hmmm
[09:37] <kiko> hmmm
[09:37] <kiko> basically
[09:37] <kiko> what I want to do is if the end-user inputs a URL
[09:37] <kiko> validate the URL against the bugtracker URL
[09:37] <kiko> and then truncate it to the remote bug id
[09:37] <kiko> which shouldn't be difficult
[09:37] <kiko> if the URL doesn't match I want to raise an error
[09:38] <kiko> and if it does I want to modify the value
[09:38] <kiko> BjornT, would a simple RemoteBugWidget allow me to do that?
[09:38] <kiko> considering the fact that it needs to know the bugtracker type and URL?
[09:39] <BjornT> kiko: no. it needs to be a BugWatchWidget, which would have access to both the remote bug, and the bug tracker.
[09:40] <kiko> BjornT, which wouldn't be usable in the edit task form, right?
[09:41] <BjornT> it wouldn't be usable directly, but BugTaskBugWatchWidget could use BugWatchWidget in order to benefit from it. that's an easy change.
[09:42] <kiko> BjornT, s/use/inherit from/ ?
[09:43] <BjornT> kiko: no, use. currently it has sub-widget, it uses a bug tracker widget, and a remote bug widget to do its work.
[09:48] <BjornT> kiko: btw, if you'd do the validation/truncation in one place, i'd be happy to create and modify the necessary widgets to make it work later.
[09:48] <kiko> BjornT, hmmm. okay. but what place would that be?
[09:52] <BjornT> kiko: what place do you think needs it the most? actually, it's probably easiest to do it in the bugtask edit page, BugTaskBugWatchWidget._toFieldValue. the other option would be on +upstreamtask, but that's quite tricky to do. i think i need to convert BugAlsoReportInView to a LaunchpadFormView in order to make it simpler first.
[09:53] <kiko> BjornT, I'll look at doing it there, then. 
[10:06] <elmo> is l.c.c the wrong place to look for remotely recent rocketfuel instructions?
[10:06] <elmo> it seems to still all be about the chinstrap
[10:06] <kiko> elmo, it's the right place, but perhaps we haven't done the s/chinstrap/sodium change
[10:06] <elmo> kiko: what about the lightweight checkout stuff?
[10:07] <kiko> elmo, using repositories? there's a page up for that as well, I believe. one sec.
[10:07] <kiko> you don't need to use them, though
[10:07] <elmo> I thought they were mandatory given the lack of space on sodium
[10:07] <elmo> but if I don't, super
[10:08] <kiko> https://launchpad.canonical.com/WorkingWithSharedRepositories?highlight=%28repositories%29
[10:11] <LarstiQ> elmo: repositories also improve speed (branch, push, pull, basically whenever a revision is already present)
[10:12] <elmo> kiko/larstiQ: thanks
[10:18] <WebMaven> SteveA: AYT?
[10:33] <sabdfl> hey kikomatic
[10:34] <sabdfl> ui team on amphetamines over here
[10:34] <sabdfl> newz2000 is suggesting stored procedures and EVERYTHING
[10:34] <sabdfl> it's going to rock
[10:47] <WebMaven> SteveA: AYT?
[10:47] <kiko> sabdfl, stored procedures?!
[10:47] <LarstiQ> WebMaven: at this hour, I wouldn't be surprised if he was asleep.
[10:48] <WebMaven> Sleep? We can sleep when we're dead.
[10:51] <LarstiQ> While I appreciate the sentiment, I also prefer SteveA not terminating prematurely.
[10:51] <kiko> WebMaven, I gave a Warren Zevon album to SteveA, coincidentally.
[10:54] <WebMaven> See? this is why vampires make the best developers.
[10:54] <kiko> he's probably offline now though
[10:55] <WebMaven> yeah, I guess. Although he's showing as online.
[10:55] <WebMaven> Not even as 'away'.
[10:55] <WebMaven> Ah well. I'll catch him later.
[10:55] <kiko> I can /kick him from #launchpad if you like though
[10:56] <WebMaven> no, let him collect the scrollback if he wants it.
[10:58] <WebMaven> Are there any Ubuntu+Python or Ubuntu+Zope channels or mailing lists?
[10:58] <kiko> hmmm, I'm not sure. I suspect not!
[11:00] <kiko> WebMaven, he's currently in London, which is why he's kind of unresponsive on IRC. I think that will be fixed this week though
[11:02] <WebMaven> Ok.
[11:04] <sabdfl> kiko: yeah ;-)
[11:04] <kiko> sabdfl, I think I am -ECONTEXT now
[11:06] <sabdfl> stored procedures
[11:06] <kiko> sabdfl, I know what they are in the SQL context. but in the UI context?
[11:06] <sabdfl> we were cooking up the mother of all charts for a bug page somewhere, which i said would crawl, and newz2k said "oh that's ok just make a stored procedure!"
[11:06] <sabdfl> crack me up
[11:06] <kiko> heh
[11:07] <sabdfl> otherwise, good progress
[11:07] <sabdfl> at the very least, 1.0 will be crisp
[11:07] <sabdfl> and clean
[11:07] <sabdfl> though not optimal
[11:08] <cbx33> Hi all, quick question regarding bug statu
[11:08] <kiko> sabdfl, as long as we're moving forward. :)
[11:08] <kiko> yes cbx33?
[11:08] <cbx33> I'm working on a package for edubuntu
[11:09] <sabdfl> sivang: ping
[11:09] <cbx33> found two bugs
[11:09] <cbx33> fixed two bugs
[11:09] <cbx33> I host a bzr branch which is registered on LP
[11:09] <cbx33> what status do I change those bugs to?
[11:10] <kiko> cbx33, the fix committed means that the fix has been committed to the product's main code repository, but no fix has been made available under a publically released version
[11:10] <kiko> cbx33, fix released means that end-users have access to released version which contains the fix.
[11:10] <cbx33> right ok
[11:10] <cbx33> that's what I thoguht
[11:10] <cbx33> thanks kiko 
[11:11] <kiko> cbx33, the main functional difference between them is that fix released makes the bug "disappear" from the default bug listings.
[11:11] <kiko> cbx33, you're welcome.
[11:11] <cbx33> yes I realised that
[11:11] <LarstiQ> which might be part of the reason why bzr uses fix released for bzr.dev
[11:12] <kiko> LarstiQ, if you do that, users may keep on filing dupes on bugs which are already fixed.
[11:12] <sabdfl> kiko: r=sabdfl on sivang's patch, i'm going to reply to him, could you land it for him, please, or delegate that?
[11:12] <LarstiQ> kiko: not happening yet
[11:12] <kiko> unless bzr.dev is what your users are using.
[11:12] <sabdfl> he will need to merge to rf head, though, after my landing
[11:12] <lifeless> morning
[11:12] <sabdfl> hi robert
[11:12] <LarstiQ> kiko: but there is a need for a 'fix merged' I think.
[11:13] <kiko> LarstiQ, that's fix committed. :)
[11:13] <kiko> sabdfl, is this the s/BRAINDUMP/NEW patch you are talking about?
[11:13] <LarstiQ> kiko: so what do you call fixes committed to a non-trunk branch?
[11:13] <kiko> LarstiQ, In Progress.
[11:13] <kiko> LarstiQ, because essentially, they are not yet final or "approved".
[11:13] <sabdfl> kiko: yes
[11:14] <lifeless> hiya sabdfl 
[11:14] <elmo> is it safe to use 0.9 for LP dev?
[11:14] <lifeless> yes
[11:14] <sabdfl> elmo: yes
[11:14] <sabdfl> encouraged
[11:14] <kiko> sabdfl, I believe I already r+ed that. I told him to get somebody to do it for him, though I can if he doesn't find anyone else
[11:14] <LarstiQ> kiko: feh, how about features/bugs _really_ in progress?
[11:14] <lifeless> kiko: we're fine with them filing dups, have you seen the wiki page where we describe how we use malone ?
[11:14] <elmo> oh, that's not what I actually wanted to ask
[11:15] <kiko> lifeless, one thing at a time.
[11:15] <kiko> LarstiQ, committing a fix to a non-trunk branch /is/ in-progress
[11:15] <kiko> LarstiQ, once the fix is generally approved and merged to the common repository, it is fix committed.
[11:15] <lifeless> kiko: okok. BTW, are you going to get that review done ? its 20 days old
[11:16] <kiko> LarstiQ, and once it is available in a public release, then it is fixed releasedd.
[11:16] <kiko> lifeless, yes, but francis is on vacation this week.
[11:16] <kiko> LarstiQ, I mean, once you have started working on something, it's fair to assume you will have committed to a non-trunk branch, right? this is bzr, after all :)
[11:16] <LarstiQ> kiko: I find the usage at http://bazaar-vcs.org/BugGuidelines more natural, apart from the abuse of Fix released, due to a missing Fix merged
[11:17] <LarstiQ> kiko: true, but finishing fixing the bug and merging it to trunk are two very distinct phases
[11:17] <bradb> bug statuses are what you make of them
[11:17] <kiko> LarstiQ, why?
[11:17] <lifeless> bradb: :)
[11:17] <kiko> LarstiQ, the fact is that until this fix has been merged into the trunk, there is no guarantee that people have actually agreed with it.
[11:18] <kiko> bradb, well, we /do/ have some semantics attached to them :-P
[11:18] <LarstiQ> kiko: people can merge the feature branch and have a working solution, instead of having to wait for it to be in trunk
[11:19] <kiko> LarstiQ, who says it's working? I suspect most projects would not feel happy with endorsing something to be "fixed" by an unofficial patch.
[11:19] <lifeless> kiko: fix committed lets mergers search for unmerged bug fixes
[11:19] <bradb> kiko: sure, but we can only try and reach a mutual understanding with our users, rather than expect they'll follow the One True Path.
[11:19] <kiko> lifeless, ah, a use case.
[11:19] <elmo> oh, gar, bzr 0.9 isn't dapper happy
[11:19] <kiko> lifeless, interesting
[11:19] <lifeless> elmo: welcome to the new python policy
[11:19] <LarstiQ> kiko: I'm really only thinking of regular contributors
[11:19] <lifeless> kiko: Martin and I spent some time working through what we need, to use malone efficiently, and we laid it out on the lp-dev list
[11:19] <kiko> LarstiQ, ISWYM, but lifeless' use case is really what I was fishing for
[11:20] <LarstiQ> kiko: I'll have to learn to that better
[11:20] <lifeless> so there is some existing discussion on that
[11:20] <kiko> his use case is "fix available"
[11:20] <kiko> I guess
[11:20] <elmo> lifeless: *whine*
[11:20] <lifeless> elmo: dude, beat up the python-bof @ debconf
[11:20] <kiko> bradb, oh, I wasn't disagreeing with LarstiQ or lifeless, but fishing for a use case as to why they used a different model
[11:21] <LarstiQ> kiko: ah hmm, I'd then make it 'Fix available' and 'Fix merged', doing away with committed
[11:21] <lifeless> we're going to do a 0.9 version for dapper-updates shortly
[11:21] <kiko> LarstiQ, yeah, but not everybody uses an RCS in which "merged" means what you do. :)
[11:21] <LarstiQ> kiko: what, there are non-bzr malone users? Heresy! :)
[11:21] <kiko> I wasn't suggesting "fix available" as a status name yet though
[11:21] <kiko> fix-in-branch, fix-on-trunk
[11:22] <kiko> fixed-in-branch, fixed-on-trunk
[11:22] <LarstiQ> fix-in-patch
[11:22] <kiko> yes, bradb, we know 
[11:22] <kiko> I like the idea too
[11:22] <kiko> but it isn't as trivial as it sounds
[11:22] <kiko> I find it interesting though that they use fix committed to communicate a fix is available for merging
[11:23] <bradb> if my brain were wired for distribution version control, i think i'd eat the definition up too
[11:24] <bradb> s/the def/that def/
[11:24] <lifeless> so
[11:24] <lifeless> lets look at it
[11:24] <lifeless> we expect 'in progress' to mean that there is at least one branch working on the bug
[11:24] <lifeless> i.e. linked branches 
[11:24] <kiko> right
[11:25] <lifeless> and once someone is finished they say that the bug-branch relationship is 'fix ready'
[11:25] <kiko> (mpool, lifeless, for BugGuidelines, btw, priority is gone)
[11:25] <kiko> right
[11:25] <lifeless> that does not mean its 'fix committed' yet
[11:25] <bradb> there's a "Fix Available" bug branch status, fwiw
[11:26] <lifeless> at this point someone/people will bless the branch, usually via the review process on the main list
[11:26] <bluefoxicy> I like bradb's idea
[11:26] <lifeless> once its blessed its 'fix committed'
[11:26] <lifeless> bradb: I meant fix available
[11:26] <bluefoxicy> fix-in-stfu-and-get-back-to-writing-patches
[11:26] <lifeless> because we are saying two specific things at this point:
[11:27] <lifeless> a) users have a branch they can merge to get a bugfix that is considered 'ok'.
[11:27] <bluefoxicy> but that would require a patch system
[11:27] <lifeless> b) there is  abranch that needs merging to the mainline
[11:27] <bluefoxicy> which would recirculate the problem
[11:27] <lifeless> bluefoxicy: uhm, can you hang on a second
[11:27] <lifeless> bluefoxicy: as you seemto be off on a tangent
[11:27] <bluefoxicy> kay
[11:28] <kiko> lifeless, do the end-users merge themselves?
[11:28] <lifeless> so fix committed shows up on https://launchpad.net/products/bzr/+milestone/0.10
[11:28] <kiko> I find it really weird to use fix committed to indicate that it is blessed.
[11:28] <lifeless> for example 55783 needs to be merged
[11:28] <kiko> errr
[11:29] <kiko> I meant to ask
[11:29] <kiko> if branch owners merged their own work into the trunk, or if somebody else merges on their behalf
[11:29] <lifeless> and for release management, this works really well
[11:29] <bradb> kiko: I don't find it confusing. Their mental model, and what's actually happened, is consistent with the status name, tbh.
[11:29] <lifeless> if the owner has pqm access then they do their own merge
[11:30] <bradb> s/confusing/weird/
[11:30] <lucasvo> how comes that on https://launchpad.net/products/harmony/trunk it says: No revision control details recorded for trunk  even though https://launchpad.net/people/harmony-dev/+branch/harmony/trunk exists?
[11:30] <lifeless> lucasvo: https://launchpad.net/products/harmony/trunk is a release series
[11:31] <lifeless> lucasvo: https://launchpad.net/people/harmony-dev/+branch/harmony/trunk is a branch
[11:31] <kiko> lucasvo, because the UI is confusing, and because the latter is a branch called trunk under the harmony-dev team, the the former is a trunk branch on the release series.
[11:31] <lifeless> currently you cannot connect the two properly. I'm writing up the shortterm fix for that today as it happens
[11:31] <lucasvo> lifeless: you guys managed to implement cvs import before linking it to bazaar? funny thing.
[11:32] <kiko> lifeless, ah, so you'll be able to say that the project is bzr-natively-hosted?
[11:32] <lifeless> kiko: yes
[11:32] <kiko> very nice
[11:33] <kiko> fixes major wart
[11:33] <lifeless> lucasvo: other way around
[11:33] <lucasvo> kiko: but one is not able to upload a bzr repo to a release series?
[11:34] <lifeless> lucasvo: cvs imports *are* linked, but you cannot use a native bzr branch as the branch for a release series yet
[11:34] <kiko> lucasvo, what lifeless just said :)
[11:35] <lucasvo> lifeless: yes, that's what I meant. How come that one cannot use a native bzr branch? are there any complications?
[11:35] <lucasvo> lifeless: importing cvs must be harder to implement. or was it needed by an important project?
[11:35] <lucasvo> *required
[11:36] <lifeless> lucasvo: we started this without intending to write a VCS
[11:36] <lifeless> back in 2004 nearly noone used distributed VCS of any sort
[11:36] <lucasvo> oh.
[11:36] <lucasvo> lifeless: I did :)
[11:36] <lifeless> you may have
[11:36] <lucasvo> I was fighting with gnu-arch all the time
[11:37] <lifeless> ah right :)
[11:37] <lifeless> so, anyhow, our models and how things relate have changed as we got better and more flexible vcs support logic
[11:37] <lucasvo> lifeless: ok, that makes sense
[11:37] <lifeless> we've only just turned off our use of gnu-arch in the cvs import process!
[11:37] <lifeless> so now we need to take advantage of the flexability bzr offers
[11:38] <lucasvo> lifeless: you mean, you were using gnu-arch for imported cvs ?
[11:38] <lucasvo> well, even without it, lp is still a lot better than source forge
[11:39] <lifeless> we were going CVS - baz1 - bzr
[11:39] <lifeless> LOTS of backend machinery to update - took some time to be sure it was solid
[11:39] <lifeless> now its CVS - bzr
[11:40] <lucasvo> nice
[11:41] <lucasvo> lifeless: when will your apply the patch?
[11:42] <lifeless> I'm not writing a patch, I'm documenting the rules a patch should enforce
[11:42] <lifeless> we have a number of states that need to be preserved/move data around on disk etc
[11:42] <lifeless> ddaa will probably be the one writing the patch, hes the one that asked me to spec it
[11:42] <lucasvo> oh, ok.
[11:43] <ddaa> what patch?
[11:45] <ddaa> lifeless: you noticed I braindumped about that on the launchpad mailing list?
[11:46] <ddaa> And that the discussion about "one or two branches in productseries" was about fixing that issue?
[11:47] <ddaa> and that since we are apparently going to go with "two branches in productseries" there's no moving around of data needed
[11:48] <lifeless> ddaa: do you still need me to spec the transitions out ?
[11:48] <ddaa> The whole point of having import_branch and explicit_main_branch in productseries is NOT to have to worry about any of those transitions.
[11:49] <ddaa> since then you can have an import and a native branch coexisting peacefully in the same series.
[11:49] <ddaa> There's going to be DB schema transition involved, but that's the only one I can think of.
[11:49] <lifeless> is that a no ?
[11:50] <ddaa> yes, that's a no
[11:50] <lifeless> so I can remove my name from the bug
[11:50] <ddaa> I already did that I think
[11:50] <ddaa> bug 31308
[11:50] <Ubugtu> Malone bug 31308 in launchpad-bazaar "Cannot set branch associated to a product series" [Critical,Confirmed]  https://launchpad.net/bugs/31308
[11:51] <ddaa> changed assignee at 2006-08-10 14:18:32 CEST
[11:51] <lifeless> ok