[00:48] <cody-somerville> lol
[00:48] <cody-somerville> Just got this error trying to instantiate a Launchpad object:
[00:49] <cody-somerville> TypeError: __init__() takes at least 4 arguments (4 given)
[00:59] <poolie> :)
[00:59] <poolie> wow
[01:07] <nigelb> Morning!
[01:13] <poolie> hi nigel
[01:13] <nigelb> o/
[01:13] <nigelb> *yawn*
[02:46] <StevenK> nigelb: Diff against target: 2522 lines (+1091/-1038) 8 files modified
[02:49] <nigelb> StevenK: You, sir, are a master :-)
[02:52]  * StevenK still needs to find someone to review it ... :-)
[02:53] <nigelb> Too bad you're OCR today :P
[02:54] <StevenK> I'm so not self reviewing a branch with a 2,500 line diff.
[02:54] <nigelb> lol
[02:54] <nigelb> Look for victims like wgrant :P
[02:58] <StevenK> nigelb: lp:~nigelbabu/launchpad/create-description-5283 is still hanging around, do you need that tossed through ec2 again?
[02:58] <nigelb> StevenK: There's a conflict
[02:58] <nigelb> Working on it today after breakfast and coffee.
[02:58] <nigelb> (Just need to create new sample data again
[02:58] <nigelb> )
[02:58] <StevenK> Like fun you do.
[02:59] <nigelb> :D
[02:59] <StevenK> Sample data needs to die, not be created.
[02:59] <nigelb> Well, sure.
[03:00] <nigelb> I don't want to break all dev machines though.
[03:00] <nigelb> But, what's the alternative to sampledata?
[03:00] <StevenK> Hm? How does no sampledata break dev machines?
[03:00]  * StevenK actually reads the diff.
[03:01] <nigelb> I thought there were legacy tests depending on sample data.
[03:02] <StevenK> I can't see a conflict in the MP
[03:02] <StevenK> And your target should be db-devel
[03:02] <nigelb> I'm pretty sure there's a conflict.
[03:02] <nigelb> I landed a db patch right before this
[03:02] <nigelb> anyway, 20 minutes and I'll post it again :)
[03:02] <StevenK> Uh? That branch *is* the DB patch?
[03:17] <sinzui> StevenK, I added a UI branch that extends the DSP vocab branch I have in review.
[03:18] <StevenK> sinzui: I have reviewed your first branch.
[03:18] <StevenK> sinzui: My mega-branch is up for review
[03:18] <sinzui> fab I will do that now
[03:30] <lifeless> nigelb: you -never- need to add sample data
[03:31] <lifeless> nigelb: you may need to tweak existing (but better to update the test that used it to not use it)
[03:31] <nigelb> lifeless: I only need to run make sampledata and do the replacement thing.
[03:48] <sinzui> nigelb, there are two sampledatas
[03:49] <nigelb> normal and dev?
[03:49] <StevenK> Testing and dev, right
[03:49] <StevenK> I think
[03:49] <sinzui> one (sampledata) is for tests and was frozen 2.5 years ago. No additions, but removals are okay. The other is sampledata-dev and it provides the data for your browser. It is good to provide sane data to look at Lp
[03:50] <StevenK> sinzui: FSVO 'sane'
[03:50] <StevenK> The publication records in sampledata are *wrong*
[03:50] <sinzui> yes!
[03:50] <nigelb> sinzui: "additions" in terms of adding new data or adding new fields?
[03:50] <StevenK> The former
[03:50] <sinzui> note in my last MP I gave instructions to populate the DSP table with proper data
[03:57] <StevenK> sinzui: I'd like to chat tomorrow about my denorm garbo job, by the way.
[03:57] <sinzui> okay
[03:57] <StevenK> It is just making no progress at all.
[03:58] <StevenK> If it isn't postgres backups, it's replication lag, and if it isn't those two, it's process-death-row.
[04:00] <lifeless> StevenK: is pdr doing long transactions ?
[04:00] <StevenK> lifeless: So before Dapper was cashiered out of the librarian, p-d-r took about 30 seconds. Now it takes 90 minutes.
[04:01] <StevenK> And we haven't done any work on it due to lol-maintaince.
[04:02] <StevenK> lifeless: But to be fair, p-d-r is a long third behind slony, backups and replication lag
[04:05] <lifeless> StevenK: ok, so it was fast enough that noone at the time considered one big xaction a problem, and now its not ;)
[04:05] <StevenK> lifeless: We probably need to just fix what it is choking over, TBH.
[04:06] <StevenK> Our represtantion of the archive is not clean in our prod db.
[04:27] <mwhudson> lifeless: so there is exactly one test that breaks if LaunchpadTestRequest sets up a real feature controller
[04:27] <mwhudson> (it's testMemcachedWorking (canonical.testing.ftests.test_layers.ZopelessTestCase), excitingly)
[04:46] <sinzui> StevenK, I could remove the maintainer. We are showing the maintainer because it is assumed that that is the person/team that will like be working with a private bug that you report
[04:47] <sinzui> StevenK, We are showing all the binary package names in the expanded details so that you can see why the source package matched
[04:47] <StevenK> I just think there is more useful information to show besides the maintainer.
[04:47] <sinzui> StevenK, we do not plan to distinguish between package, the bugs about assign to a package make it clear users do not want to think about source and binary
[04:48] <StevenK> sinzui: Oh, is it supposed to be an icon rather than the word?
[04:49] <sinzui> Just the word, to be consistent with the case when we show project group, project, and distribution in target pickers
[04:49] <StevenK> Right
[04:50] <sinzui> Since we are going to show all the binary names, I think the maintainer is the big issue here.
[04:50] <sinzui> StevenK, That value changes if the uploader changes right?
[04:51] <StevenK> Which property of bpr/spr are you using?
[04:53] <sinzui> StevenK, dsp.currentrelease.maintainer.displayname
[04:54] <sinzui> That is the SPR for the current series
[04:55] <StevenK> If maintainer is pulled from the source package itself, it's going to be "Ubuntu Core Developers" for an awful lot of the archive.
[04:58] <sinzui> StevenK, that is interesting. If I were reporting a bug in a future private distro derived from oneiric, are "Ubuntu Core Developers" the group who will be seeing the bug besides the private distro owners?
[04:58] <lifeless> mwhudson: win
[04:59] <StevenK> sinzui: Perhaps. We haven't designed private distros yet. :-)
[04:59] <sinzui> We may need to fix the dsp bug supervisor role/policy which is an old bug
[04:59] <nigelb> Ok, breakfast has been had. Now to finish off those MPs.
[05:00] <sinzui> StevenK, Do you want me to remove the maintainer? Force it to None so that it can be discusses at a later time, or keep it as it is?
[05:01] <StevenK> sinzui: I like the idea of removing it so we can discuss it later.
[05:01] <sinzui> I will remove it
[05:02] <sinzui> StevenK, do you need any more information?
[05:03] <StevenK> sinzui: I think that's it.
[05:03] <sinzui> thanks. I will do this now.
[05:10] <mwhudson> argh everything is horrible
[05:10]  * mwhudson gives up for today
[05:11] <nigelb> Launchpad - "argh everything is horrible"
[05:12] <StevenK> Sounds right to me.
[05:14] <nigelb> grar
[05:14] <nigelb> I should redo this entire branch.
[05:15] <StevenK> It sometimes comes to that.
[05:15] <StevenK> bzr di > /tmp/foo ; cd .. ; rm -rf <branch>
[05:15] <nigelb> hrm. Ouch
[05:15] <nigelb> I deleted that as well.
[05:16] <StevenK> The fact that I typed it quickly is in no way a sign of how often I do that ...
[05:17] <nigelb> I did, however, save the db patch file.
[05:17] <nigelb> So, if I'm not mistaken, all is not lost :D
[05:17] <StevenK> If the branch is still on LP, you can grab it again
[05:18] <nigelb> It is \o/
[05:18] <nigelb> DVCS++
[05:18] <nigelb> Reminds of the poor soul in this one http://programmers.stackexchange.com/questions/112270/small-company-15-developers-doesnt-use-managed-source-version-control-is-thi
[05:20] <StevenK> nigelb: Cold sweat.
[05:21]  * StevenK resubmits his MP, due to the diff going from 243 lines to 2788 ...
[05:23] <nigelb> when I add a column, do I force default NULL or do I just leave it alone?
[05:24] <nigelb> ohwait. This has db ack.  I should not be worrying about this.
[05:26] <nigelb> help -> http://paste.ubuntu.com/702588/
[05:27] <StevenK> bin/py doesn't exist, run make
[05:27] <nigelb> ah
[05:28] <nigelb> grr
[05:28] <nigelb> Getting distribution for 'txlongpollfixture==0.1.3'.
[05:28] <nigelb> make: *** [/home/nigelbabu/launchpad/lp-branches/create-description-5283/bin/py] Error 1
[05:28] <StevenK> rf-get
[05:28] <nigelb> already started :)
[05:28] <StevenK> Or update your download-cache
[05:28] <StevenK> Either way, blame Red Squad
[05:28] <nigelb> I was about to say #blame-bigjools but that works :D
[05:29] <StevenK> Right, I think that MP is squared away until the previous pipe lands and wgrant re-surfaces.
[05:31] <nigelb> Is he off this week?
[05:32] <StevenK> No, just today.
[05:32] <nigelb> He should be online in an hour :P
[05:33] <StevenK> Perhaps. I know what he's doing today, and he may not be.
[05:33] <nigelb> Ah.
[05:34] <nigelb> Do you both live in the same city btw?
[05:34] <StevenK> No, wgrant is in Melsbum.
[05:35] <nigelb> And you?
[05:35] <StevenK> Sydney
[05:35] <nigelb> AH
[06:57] <wgrant> StevenK: Is the refactoring pipe reviewed?
[07:03] <poolie> stub, if you can also give any suggestions on how to improve bug 868021 i'd appreciate it
[07:04] <_mup_> Bug #868021: +affectingbugs times out <affectsmetoo> <bugs> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/868021 >
[07:04] <stub> poolie: I've already added some reworked queries there.
[07:04] <poolie> :)
[07:04] <stub> poolie: Bringing a 9s query down to subsecond. I haven't gone over the OOPS report now it should have synced.
[07:07] <poolie> really 868021?
[07:07] <poolie> the other similar one, 866100, we tried your queries and they're generally good but intermittently slow
[07:08] <poolie> perhaps in a way that varies by db server
[07:11] <stub> Sorry, thinking of the other bug
[07:11]  * stub looks
[07:11] <StevenK> wgrant: The pre-req branch was +1'd by Curtis.
[07:11] <StevenK> wgrant: I had to resubmit the second branch because of it, so it needs your +1 again.
[07:12] <stub> poolie: I suspect fixing Bug 866100 would address Bug 868021 too
[07:12] <_mup_> Bug #866100: bug search with affects_me=on times out <affectsmetoo> <bugs> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/866100 >
[07:12] <_mup_> Bug #868021: +affectingbugs times out <affectsmetoo> <bugs> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/868021 >
[07:12] <wgrant> StevenK: Ah, great. Will hopefully look later tonight.
[07:13] <poolie> stub, yes i wasn't sure whether it made sense to split them or not
[07:13] <StevenK> wgrant: I'm in no rush, since I want the pre-req to land first.
[07:13] <poolie> but since the conversation was getting a bit long i thought i would split
[07:14] <stub> poolie: separate bugs could be fine, but I'd tackle the simpler case first.
[07:15] <poolie> and 866100 is simpler?
[07:15] <poolie> ok great
[07:19] <stub> poolie: 866100 is simpler because I've done diagnosis :-)
[07:20] <stub> poolie: I'm just assuming 868021 may be fixed as a side effect, as the trigger condition is the same (bugaffects clause)
[07:25] <nigelb> StevenK: lol, wgrant did come online in about 1.5 hours :D
[07:27] <wgrant> Indeed!
[07:51] <allenap> nigelb: Your download-cache is out of date.
[07:51] <nigelb> allenap: yeah, fixed that.
[07:51] <allenap> nigelb: Cool :)
[07:53] <bigjools> morning everyone
[07:54] <nigelb> Hello bigjools!
[07:54] <bigjools> hey nigelb
[07:56] <nigelb> Hrm
[07:56] <nigelb> someone changed 2010 to 2010-2011 in current.sql
[07:56] <nigelb> Is a better fix to fix whatever generates newsampledata.sql?
[08:01] <mrevell> Hello
[08:02] <nigelb> Hey mrevell :)
[08:25] <nigelb> StevenK: ohai, still around?
[08:29] <StevenK> nigelb: Barely
[08:30] <nigelb> StevenK: oh. I was just about to put that MP into your queue. Nevermind, I'll catch the euro train :)
[08:48] <nigelb> allenap: Hi, OCR'ing today? :)
[08:54] <allenap> nigelb: My day is tomorrow... let me see who's on call...
[08:56] <allenap> nigelb: danilos is down for the EU slot today (jtv too, but he's away). Aaron is on later. If it's something small I don't mind taking a look though.
[08:57] <nigelb> allenap: bah, right. My bad. I looked at Thu instead of Wed.
[08:58] <nigelb> Its an approved db patch which I couldn't land because of conflicts - https://code.launchpad.net/~nigelbabu/launchpad/create-description-5283/+merge/76818
[08:58] <nigelb> I made one extra change in database/schema/Makefile
[09:27] <danilos> allenap, thanks for the reminder :)
[09:30] <danilos> nigelb, btw, why did you not just merge the db-stable instead of starting from scratch?
[09:31] <nigelb> danilos: Well, I screwed up massively :D
[09:31] <danilos> nigelb, right, but in this case, I'd have to ask you to make a new merge proposal and get patches reviewed again, because we can't tell if they are the same or not
[09:32] <nigelb> ahhh.
[09:32] <nigelb> db review?
[09:32] <danilos> nigelb, yeah, db review as well
[09:32]  * nigelb does that.
[09:34] <nigelb> *faceplam*
[09:34] <nigelb> why did I just delete the branch.
[09:34] <danilos> nigelb, btw, did you use "bzr push --overwrite" for this?
[09:34] <nigelb> danilos: I did.
[09:35] <danilos> nigelb, right, well, that makes any merge proposals you've got invalid since you are changing the branch history behind LP's back :)
[09:35] <danilos> nigelb, whoops :)
[09:35] <nigelb> danilos: Ah. Drat. Anyway, its nicer this way.
[09:36] <danilos> nigelb, nicer? if you are refering to "bzr push --overwrite", it's not, just a simple "bzr merge lp:~launchpad-pqm/launchpad/db-stable && resolve conflicts && bzr ci -m 'Merge db-stable.'" is the best thing to do
[09:37] <danilos> nigelb, the thing you did was basically rebasing, bzr doesn't require that at all :)
[09:37] <danilos> nigelb, and your revision will end up as one revision when it's finally merged anyway
[09:37] <nigelb> well, at some point of cleaning this up, I lost of track of what I was doing.
[09:38] <nigelb> But yeah, noted for next time.
[09:38] <nigelb> stub: hi, around?
[09:38] <nigelb> stub: Need a re-ack of a db patch because I messed it up :)
[09:39] <danilos> nigelb, I am sorry to cause you more work :/
[09:40] <nigelb> danilos: heh, np. I think I shot myself in the foot there :D
[09:48] <nigelb> https://code.launchpad.net/~nigelbabu/launchpad/create-description-5283/+merge/78220
[11:55] <nigelb> mrevell: around?
[11:56] <mrevell> I certainly am nigelb
[11:56] <nigelb> mrevell: I was reading about Open Badges, it certainled seemed interesting to think of LP giving out badges for certain things - http://openbadges.org/About/
[11:56] <nigelb> *certainly
[11:57]  * mrevell looks
[11:57] <mrevell> Hmm, interesting.
[11:57] <G> nigelb: do systems like that really do anything though?
[11:58] <nigelb> G: Well, this is the first such system.
[11:58] <G> nigelb: I can understand in the context of Four Square, but in software development, I'm not sure
[11:58] <nigelb> Its about showing your achivements in learning/coding.
[12:03] <G> nigelb: the way I personally see it (and this is my own warped mind) but I think that sorta stuff is just 0 value fluff
[12:03] <nigelb> G: Well, karma is 0 value as well.
[12:03] <nigelb> I'd like to able to show off my skills
[12:03] <nigelb> Like coderwall
[12:03] <nigelb> Or like stackoverflow
[12:59] <nigelb> Hrm, what does fixing bug 184737 involve?
[12:59] <_mup_> Bug #184737: No tag autocomplete or official list in +filebug extra options <bugtag> <filebug> <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/184737 >
[13:00] <nigelb> I think there's some code I can reuse from the tag autocomplete in the bug's index page
[13:27] <nigelb> gary_poster: tech-debt helps. I often look into it for bugs to fix :)
[13:27] <gary_poster> nigelb, cool :-)  please reply with that note then
[13:32] <nigelb> Whoever did the logpoll documentation has a *lot* of patience.
[13:32] <nigelb> The diagram is ascii is pretty awesome
[13:32] <rvba> nigelb: ;)
[13:39] <deryck> Hi adeuring.  I didn't ping for the standup.  I assumed you weren't around until top of the hour.  Sorry.
[13:39] <deryck> adeuring, just noticed you here :)
[13:39] <adeuring> deryck: ok, I'll join
[13:40] <deryck> adeuring, oh, we're done now.
[13:40] <adeuring> deryck: yeah, noticed that too :) no problem
[13:40] <deryck> adeuring, I was apologizing for not inviting you in. :)
[13:58] <deryck> abentley, adeuring -- ready for skype?
[13:58] <adeuring> deryck: yes
[13:58] <abentley> deryck: yes
[13:58] <deryck> restarting… you guys don't show for me
[13:59] <abentley> deryck: I've had that plenty.  Just call me anyway.
[13:59] <deryck> abentley, we don't hear you.  hear us?
[14:00] <abentley> deryck: yes.
[14:00] <abentley> deryck: grr
[14:01] <deryck> abentley, should we drop you and add you back?
[14:01] <abentley> deryck: sure.
[14:03] <mrevell> Hey sinzui?
[14:37] <danilos> sinzui, hi, did you ever figure out the oneiric librarian problem?
[14:37] <sinzui> no I did not
[14:53] <sinzui> matsubara, http://pastebin.ubuntu.com/702790/ the top 12 bugs
[14:53] <matsubara> thanks sinzui
[15:05] <deryck> abentley, mumble?
[15:34] <bac> abentley: are you OCR today?
[15:38] <sinzui> gary_poster, I do not think anything should high in launchpad-results. cr3 created it we may maintain it, but we never hack on it
[15:38] <timrc> approximately how long do the code updates on staging take?
[15:38] <timrc> and is there a notification system for updates so I can plan around it?
[15:38] <gary_poster> sinzui: oh, we maintain it?  I thought this was kind of an odd triaging experiment for traiging someone elses code
[15:39] <gary_poster> where "odd" means "I don't care for it" :-)
[15:39] <sinzui> oh, we do not maintain it
[15:40] <gary_poster> timrc, I'm not sure, but IIRC staging is having a long outage because of some db issues
[15:40] <gary_poster> where long means 24 hours AFAIK
[15:40] <sinzui> gary_poster, This is a case of community vs organisation. Like most canonical project groups. ours is intended to be what we own. but anyone can add their project to someone elses project group.
[15:40] <timrc> noooo
[15:40] <gary_poster> normally I assume updates are similar to qastaging: just a few minutes
[15:40] <sinzui> gary_poster, The consequence of this is that we are triaging their bugs.
[15:40] <sinzui> This is bad
[15:41] <gary_poster> agreed sinzui
[15:41] <sinzui> ~launchpad-results needs to do this, maybe he should remove this project from our project group
[15:42] <gary_poster> sinzui, if we want the policy of "just triage other peoples bugs as low" I guess that is fine with me, though I think that policy should be publicized.  I was going with the policy of "why the heck is this in front of me?  I'll make arbitrary decisions."  I thought Francis spoke with Marc about this already and for some reason they agreed it would stay where it is
[15:43] <sinzui> okay
[15:44] <gary_poster> but I really just agree with you: I wish it were not
[15:44] <cr3> sinzui: someone suggested that maybe launchpad-results shouldn't be under ~launchpad, but there was a wiki page about projects related to launchpad saying otherwise. I've been meaning to touch base with lifeless about it but haven't gotten around to it
[15:44] <gary_poster> cr3, the only reason I care in this case is that it means we triage your bugs, because we are supposed to drive the count to zero
[15:44] <gary_poster> So I stomp on you
[15:45] <gary_poster> And don't like it :-(
[15:46] <sinzui> cr3, This is a common problem. The problem is that project groups look like communities, but all the code implies it is organisations. We are still discussing the removal of groups
[15:47] <cr3> gary_poster: since this is a recurring problem, I could remove launchpad-results being "part of" launchpad-project and maybe we could change that again later
[15:48] <gary_poster> bigjools, you around?  I've tried to figure out what to do with https://bugs.launchpad.net/launchpad/+bug/868366 but simply don't understand enough.  Could you let me know what you think about triage?
[15:48] <_mup_> Bug #868366: Diff from current Ubuntu version to current Debian version pending sync missing from +localpackagediffs page <Launchpad itself:New> < https://launchpad.net/bugs/868366 >
[15:48] <cr3> done, I hope that helps a bit drive your bug count to zero... a good source of inspiration for me too :)
[15:49] <gary_poster> cr3, thank you. :-) we drive *triage* count to zero every day, which is what this is about.  sadly, not so much for the bug count
[15:49] <cr3> gary_poster: an unfortunate side effect is that your drive was a bit contagious being part of your group :)
[15:49] <bigjools> gary_poster: sure thing
[15:49] <gary_poster> cr3 lol
[15:49] <gary_poster> thanks bigjools
[15:50] <cr3> gary_poster: I agreed to try and adhere to your policy of driving the triage to zero for launchpad-results but I don't quite have the same level of vanguard as your team :(
[15:50] <gary_poster> cr3, you are a team of 1 for this, right?  Understandable, I think.
[15:51] <cr3> gary_poster: an army of 1! :)
[15:51] <gary_poster> :-)
[15:54]  * gary_poster must go babysit during lunch. :-)  biab
[15:55] <abentley> bac: theoretically, but we have three job interviews today, so I haven't been able to do any.
[15:57] <deryck> abentley, Skype time.
[15:58] <abentley> deryck: online.  Even if it doesn't look like it.
[16:00] <abentley> deryck: had to restart skype.  b
[16:00] <abentley> deryck: back online.
[16:14] <sinzui> jcsackett, mumble?
[16:14] <jcsackett> sinzui: sure.
[16:34] <deryck> abentley, he called me on regular skype
[16:34] <deryck> abentley, adeuring adding you back now
[16:34] <abentley> deryck: cool
[16:34] <adeuring> ok
[17:04] <timrc> has any one experienced random failures with syncSources()? I tried syncing a package between two ppas it failed the first time and succeeded the second time.
[17:04] <timrc> this is on production
[17:05] <timrc> http://paste.ubuntu.com/702853/
[17:05] <timrc> it looks like a BadRequest exception was raised
[17:07] <timrc> hm, actually, there is an oddity and so now I'm leaning towards a bug in my code
[17:07] <timrc> wait, was looking at wrong ppa, back to thinking it's a problem with launchpad
[17:23] <sinzui> gmb r=me
[18:17] <lifeless> yawn, morning
[18:18] <lifeless> cr3: hi
[18:20] <cr3> lifeless: hola senor
[18:20] <lifeless> you invoked me earlier ;)
[18:21] <cr3> lifeless: you might've noticed I mentionned your name earlier, do you think launchpad-results should be a "part of" launchpad-project?
[18:21] <cr3> lifeless: the problem we've encountered is that the ~launchpad folks are driving bug triage to zero more quickly than me, so the bugs for launchpad-results are appearing on your radar
[18:21] <lifeless> cr3: given your goals, definitely :) - that is, becoming a component, with ui in the main tree, backend as a microservice etc.
[18:22] <lifeless> cr3: what makes that a problem ?
[18:22] <lifeless> (it sounds like a benefit to me :))
[18:22] <cr3> lifeless: the "radar" part seems to be a problem where folks on launchpad have felt the need to set the status to triaged but feeling uncomfortable doing so on behalf of a project they are not familiar with
[18:23] <cr3> lifeless: it has more than benefited me, it has actually inspired me to keep up with the same level of bug management as launchpad, but I'm afraid about the making others uncomfortable part which makes me uncomfortable as a result :)
[18:24]  * lifeless blinks
[18:24] <lifeless> cr3: the lp CHR gets uncomfortable ?
[18:24] <cr3> lifeless: CHR?
[18:24] <lifeless> the rota
[18:25] <lifeless> (the folk doing bug triage do so on a rota basis, sharin the load around)
[18:25] <cr3> lifeless: still lost me, rota == person on rotation, ie vanguard?
[18:25] <cr3> lifeless: it seems like they're seeing bugs against launchpad-results and the general reaction is: wtf!
[18:25] <lifeless> ok
[18:25] <lifeless> have you read https://dev.launchpad.net/BugTriage ?
[18:27] <cr3> lifeless: I think I did but I'll read it again. I remember at some point I read something and agree to follow the same process as launchpad, not to make you guys happy as much as because it would benefit the launchpad-results project to follow such a process :)
[18:27] <lifeless> righto
[18:27] <lifeless> so the next question was, have you been happy with the results of the lp team doing triage in -results ?
[18:27] <cr3> lifeless: however, I haven't been quite as fast at triaging bugs as the CHR. there's also the importance of bugs to consider, "high" just for launchpad-results might mean something different than "high" for the launchpad project as a whole
[18:27] <lifeless> e.g. are they identifying high/critical/low for you sensibly ?
[18:28] <cr3> lifeless: I've been happy and I've tried to return the favour as best I can, but there's also the above mentionned problem about importance that might need some tweaking
[18:28] <lifeless> cr3: I think we want to avoid having different rules; but the rules in BugTriage should be broadly compatible.
[18:29] <lifeless> cr3: if (say) most of the time the triager gets it right, and you need to tweak some to be accurate - thats fine [that happens within LP too]
[18:29] <cr3> lifeless: ok, so "high" would mean the same to all of us: likely to get attention within the next six months, no matter which team actually does the fixing
[18:30] <lifeless> yes; the folk doing triage are expected to be *broadly* aware of projects underway across LP (otherwise we could use a bot and make everything not-critical low :P)
[18:31] <cr3> lifeless: sounds good to me, I removed launchpad-results from launchpad-project earlier but I'll add it again. thanks for making sense of all this! :)
[18:31] <lifeless> so I don't think we would want - or be able to sustain - different rules for -results. OTOH I think the same rules should work for -results :)
[18:31] <lifeless> cr3: have you announced on -dev that it was part of -project, and the consequences? (Or would you like Francis or I to do so ?)
[18:32] <cr3> lifeless: perhaps I should do that myself so that I could answer most questions as a result
[18:33] <cr3> thanks for offering though, it makes the project feel welcome :)
[18:34] <lifeless> good!
[18:40] <lifeless> flacoste: did you see http://h30565.www3.hp.com/t5/Feature-Articles/Innovate-or-Suffer-Slow-Brain-Asphyxiation/ba-p/499 ?
[18:41] <flacoste> lifeless: i saw, didn't read it yet though
[18:42] <lifeless> worth a quick read, I think you'll nod in agreement all the way through; some nice physiological references connected to reward programs.
[18:42] <lifeless> flacoste: you may want to chase those for your upcoming task ;>
[18:53] <flacoste> lifeless: i actually start researching the issue, and found the evidence-based management work of Pfeffer and Sutton very interesting
[19:11] <sinzui> jcsackett, gary_poster is bragging about his madd html5 cross-domain scripting skillz. Maybe you want to talk to him about bug 823471 and get his comments on to the bug
[19:11] <_mup_> Bug #823471: privacy ribbon does not appear on secondary sites <disclosure> <Launchpad itself:Triaged> < https://launchpad.net/bugs/823471 >
[19:12]  * gary_poster snorts
[19:12] <jcsackett> sinzui: did you just actually use "mad skillz"?
[19:12] <jcsackett> :-P
[19:12] <sinzui> My fingers did
[19:12] <jcsackett> sure, blame it on the fingers. :-P
[19:13] <jcsackett> gary_poster: you likely to be free tomorrow morning-ish to talk about cross-domain scripting?
[19:14] <gary_poster> jcsackett, on call, and not quite clear on what you want, but happy to talk later.  Sure, sounds good.  It would be late morning--I have a call at 9 and one at 10, so 10:30 or 11
[19:14] <jcsackett> works for me. i'll ping you tomorrow then. :-)
[19:14] <gary_poster> cool jcsackett, I look forward to it
[20:34] <sinzui> lifeless, may I call you on skype?
[20:34] <lifeless> sinzui: I will ping you in ~5, gotta wrap ELOCAL with the cats.
[20:34] <sinzui> okay
[20:42] <lifeless> sinzui: ping
[20:43] <sinzui> calling
[21:37] <lifeless> sinzui: ping
[21:46] <lifeless> sinzui: I am back, should you wish to continue
[21:46] <lifeless> sinzui: I am going to start digging into updating LP for the latest round of oops changes, so just call me on skype whenever
[22:09] <mwhudson> any reviewer around? https://code.launchpad.net/~mwhudson/launchpad/unconditionally-endInteraction-after-test/+merge/78324
[22:10] <mwhudson> i guess abentley is no longer on call, seeing as he is not online any more
[22:14] <StevenK> mwhudson: r=me
[22:14] <StevenK> mwhudson: Sorry, I was waiting for the diff to update.
[22:14] <mwhudson> ah right yeah
[22:14]  * lifeless closes the window
[22:15] <mwhudson> the update was removing exactly two empty lines :-)
[22:15] <mwhudson> thanks!
[22:16] <mwhudson> i wonder why ec2 test remangles the postgres config each time
[22:16] <mwhudson> surely that could be done in the image?
[22:16] <mwhudson> ah well
[22:24] <lifeless> sinzui: (hi)
[22:24] <sinzui> lifeless, hi. wgrant and I will want to talk to you on skype shortly
[22:24] <lifeless> ok
[22:28] <micahg> so, I need to have multiple teams be non-members so as to not grant upload rights, is the only way to do this currently to make a single team containing the others set as owner?
[22:28] <wgrant> micahg: The owner of a PPA primarily indicates upload rights.
[22:29] <wgrant> micahg: If people should not have upload rights, they are not the owner.
[22:29] <micahg> wgrant: sorry, this is for the archive, not PPA
[22:30] <micahg> owner of a team w/upload rights  doesn't grant upload rights to the archive
[22:30] <wgrant> "I need to have multiple teams be non-members so as to not grant upload rights"
[22:30] <micahg> right :)
[22:30] <wgrant> I'm confused.
[22:30] <wgrant> Just don't add them to the team?
[22:30] <micahg> wgrant: so, these teams need to administer, but not gain rights
[22:31] <micahg> example: DMB and Edubuntu Council can approve edubuntu-dev, but neither team should have upload rights to the edubuntu packageset
[22:32] <wgrant> You'll need to create a new team, right.
[22:42] <micahg> is it worth filing a bug for a feature request to have multiple non-member admins?
[22:52] <lifeless> sinzui: I am here when you want me
[22:53] <sinzui> lifeless, I will start dinner near. wgrant and wallyworld_ will be ready in about an hour
[22:56] <lifeless> kk
[23:05] <lifeless> stub: how goes slonyI-2?
[23:08] <stub> Migration process all thought through. Mulling over how to best do the migration script so it runs with as little modification on production after testing on staging.
[23:08] <lifeless> woo
[23:08] <wgrant> We're not just going to dump and rebuild the slaves?
[23:08] <wgrant> s/dump/nuke/
[23:09] <stub> We could, or we could make use of the Slony-ii 2.0 feature that lets us skip that.
[23:09] <lifeless> what are the tradeoffs?
[23:09] <stub> 'subscribe, and btw. all the data is already there and up to date so no need to recopy it'
[23:10] <wgrant> Oh.
[23:10] <stub> lifeless: If we rebuild the slaves, they are freshly packed. But better to do that one at a time after the update anyway.
[23:10] <wgrant> Didn't know it could do that.
[23:11] <lifeless> stub: if a slave is not identical, will slony as a whole barf, or just that node ?
[23:11] <lifeless> stub: (at the first inconsistent update, I mean)
[23:11] <stub> lifeless: We won't know about it until the first inconsistent update, at which point that slave will stop replicating.
[23:11] <lifeless> ok
[23:12] <wgrant> But that's no worse than would happen if it were inconsistent already.
[23:12] <stub> The migration scripts are more complex though, as we will be dealing with all 7 nodes instead of just the 2 master nodes.
[23:13] <wgrant> Will we have to run SSO from a detached slave for the duration, or can we install it live?
[23:13] <stub> SSO has some sort of read only mode it uses, and the downtime should only be a minute or two anyway.
[23:13] <wgrant> Right, but it presumably needs an accessible slave :)
[23:14] <stub> I dunno. It always seemed problematic before and we do so few updates to that system it is always new and exciting.
[23:14] <wgrant> Heh.
[23:15] <stub> Might be pulling stuff in from cache.
[23:15] <wgrant> I don't know what the SSO SLA is these days.
[23:15] <wgrant> I suspect its availability hardly exceeds Launchpad's new process, though.
[23:20] <lifeless> hmm, need a new storm code drop
[23:20] <lifeless> not today.
[23:21] <wgrant> 0.19's about to be released, did you see?
[23:22] <wgrant> lifeless: Also, set_up_tacfile_logging is terribly buggy and responsible for a number of poppy-sftp issues.
[23:22] <wgrant> So any attempt to remove it would be most welcome.
[23:23] <wgrant> Oh, 0.19 is actually out now.
[23:24] <StevenK> They've actually made a storm release?
[23:25] <wgrant> Not quite a year since the last one.
[23:25] <lifeless> sure, I've made some notes about how in the bug
[23:25] <lifeless> I think a good twisted component is the first step
[23:26] <lifeless> .
[23:38] <StevenK> wgrant: You were saying something about parent class ordering for my branch?
[23:39] <wgrant> Oh right.
[23:42] <wgrant> Bear with me, Optus is only routing some of the DC subnets.
[23:43] <wgrant> StevenK: BasePesronEditViewWidget? Why not just put it in BasePersonEditView?
[23:43] <wgrant> Otherwise it should be something about checking renames, not BasePersonEditViewWidget.
[23:44] <StevenK> Because TeamEditView also needs it
[23:44] <wgrant> Also, remember that the MRO is first base class to last.
[23:44] <wgrant> So you probably want that setUpWidgets mixin early in the base list.
[23:44] <StevenK> And I wasn't sure about the schema set in BasePersonEditView
[23:45] <StevenK> wgrant: So if you think using BasePersonEditView is okay for both, I'm happy to try it.
[23:45] <wgrant> I'm not sure what's in it.
[23:46] <wgrant> But the current name is silly, and it would be handy if we didn't have a dozen base classes shared between those views when we only need one.
[23:46] <StevenK> A schema, fields, action_save and next_url
[23:52] <wgrant> StevenK: Perhaps a PersonRenameFormMixin?
[23:53] <StevenK> wgrant: I've put it into BasePersonEditView, what could possibly go wrong.
[23:54] <StevenK> Bah
[23:54] <StevenK> BasePersonEditView defines field_names as [], and TeamFormMixin as a large array