[00:20] <cjohnston> I'm trying to pull the summary from a spec, but it doesn't seem to be working. I am using elem.get just like I did for all the other info I am getting, but this one isn't working.
[00:20] <cjohnston> Any ideas?
[00:20] <wgrant> cjohnston: Isn't working?
[00:20] <wgrant> And which library are you using? That doesn't look like launchpadlib.
[00:21] <lifeless> http://blog.bitbucket.org/2011/07/07/redesigned-commits-screen/
[00:21] <cjohnston> simplejson
[00:22] <wgrant> It's there.
[00:23] <cjohnston> wgrant: http://pad.ubuntu.com/dYgqgL4JaA
[00:24] <wgrant> cjohnston: It's in the JSON that LP sends, but I don't know how you are getting the JSON.
[00:24] <cjohnston> wgrant: http://bazaar.launchpad.net/~summit-hackers/summit/1.x/view/head:/summit/schedule/models/meetingmodel.py#L188
[00:29] <cjohnston> Does that give you any more info wgrant ?
[00:29] <wgrant> cjohnston: Not really. Launchpad is sending the correct JSON, so you'll need to check the JSON you have.
[00:29] <jelmer> wgrant: hi
[00:30] <wgrant> jelmer: Hi.
[00:30] <jelmer> wgrant: You tried to land lp:~jelmer/launchpad/publisher-use-debian-2  earlier but it failed for some reason, do you know what it was?
[00:31] <wgrant> Hmm, I recall I ran it through ec2, but cannot find an email about it..
[00:31] <jelmer> wgrant: no worries, I'll have another look at it
[00:31] <jelmer> wgrant: thanks
[00:32] <wgrant> Sorry.
[00:33] <jelmer> wgrant: Don't be :) I appreciate you trying to land it, when I didn't have time to.
[00:34]  * jelmer gets some sleep
[00:35] <wgrant> Night.
[02:06] <lifeless> does anything still use BranchSparkView ?
[02:08] <wgrant> Heh
[02:08] <StevenK> lifeless: A bunch of tests?
[02:09] <lifeless> nuke from orbit time
[02:09] <wgrant> It was disabled during 3.0, to be fixed and revived within a month.
[02:09] <StevenK> And IBranch:+spark
[02:09] <StevenK> lifeless: Are you nuking it?
[02:10] <lifeless> StevenK: not right now, I have managerial thingies to do
[02:10] <lifeless> then some folk from .au are dropping by before they head home
[02:10] <lifeless> if you are interested in nuking it, please do.
[02:10] <lifeless> [red button]
[02:10]  * lifeless pushes the red button
[02:38] <StevenK> wgrant: Can haz review? https://code.launchpad.net/~stevenk/launchpad/destroy-branchsparkview/+merge/68627
[02:38] <wgrant> StevenK: What about the JS?
[02:38] <StevenK> There's JS?
[02:38] <wgrant> That view provides JSON to the JS.
[02:40]  * StevenK looks for the JS
[02:42] <StevenK> wgrant: Three more methods found and destroyed, but the JS is proving harder to locate.
[02:43] <wgrant> Already removed in r9680
[02:45] <StevenK> Ah, so the JS is long-dead
[02:50] <StevenK> wgrant: No review, then? :-)
[02:51] <wgrant> It is reviewed.
[02:51] <wgrant> Was just checking you'd got all of it.
[02:51] <StevenK> Ahhh
[02:51] <StevenK> I got all of it after I killed the other 3 methods?
[02:51] <wgrant> Yes
[02:51] <StevenK> Excellent, thanks
[04:35] <lifeless> righto, time to write up docs
[04:35] <lifeless> StevenK_: thanks for fixing that timeout!
[04:35] <lifeless> (+spark)
[04:35] <StevenK_> Haha
[04:35] <StevenK_> lifeless: Is there a bug about it?
[04:37] <lifeless> none filed yet
[04:37] <lifeless> it was 1/0 in todays timeout report
[04:38] <StevenK_> lifeless: Fair enough. My branch is currently ec2ing
[04:38] <lifeless> no-qa is fine IMO
[04:38] <lifeless> I'm just happy  :)
[04:40] <wgrant> Aha!
[04:40] <wgrant> An excuse to kill IUpstreamBugTask and co.
[04:40] <StevenK> Oh?
[04:40] <wgrant> Do you know of it?
[04:41] <wgrant> IUpstreamBugTask, IProductSeriesBugTask, IDistroSeriesBugTask, IDistroBugTask are marker interfaces.
[04:41] <StevenK> Nope
[04:41] <wgrant> Which need to change when the target of a task changes.
[04:41] <wgrant> Which means that retargetting bugs between target types needs to change them.
[04:41] <wgrant> But that makes lazr.lifecycle sad.
[04:42] <wgrant> So, I may finally kill them.
[04:42] <StevenK> More code deletion? :-)
[04:42] <wgrant> Since there's just about no good reason to have them.
[04:42] <wgrant> There are only a couple of places that care, and they can just check the interfaces of the target directly.
[04:48] <LPCIBot> Yippie, build fixed!
[04:48] <LPCIBot> Project db-devel build #739: FIXED in 5 hr 38 min: https://lpci.wedontsleep.org/job/db-devel/739/
[05:13] <StevenK> wgrant: Do you know if dogfood has query logging on?
[05:13] <wgrant> StevenK: It doesn't seem to.
[05:14] <StevenK> I am disappoint.
[05:14] <wgrant> Ja.
[05:14] <wgrant> OTOH the disk space would probably be sort of bad.
[05:14] <StevenK> Meh, mawson has 150GiB free :-P
[05:14] <wgrant> Now :)
[05:19]  * StevenK peers at database/schema/launchpad.html
[05:31] <StevenK> Hmmm. 450 results for '%ubuntu%' in PillarName
[05:32] <StevenK> At least one of them is the distribution itself.
[06:02]  * wgrant headdesks.
[06:02] <StevenK> wgrant?
[06:02] <wgrant> -        else:
[06:02] <wgrant> -            assert (
[06:02] <wgrant> -                "Expected IDistroSeriesBugTask or IProductSeriesBugTask. "
[06:02] <wgrant> -                "Got: %r" % bugtask)
[06:03] <wgrant> There should really be a warning for that.
[07:25] <adeuring> good morning
[07:38] <jtv> hi adeuring
[07:38] <jtv> oh, and hi rvba!
[07:39] <adeuring> hi jtv
[07:39] <jtv> wgrant: I take it the cocoplum rollout succeeded then?
[07:39] <wgrant> jtv: Soyuz only had unrelated OOPSes this morning, so yup, seems like it all went OK.
[07:40] <rvba> hi jtv!
[07:40] <jtv> Great.
[07:40] <rvba> Good morning all.
[07:40] <jtv> wgrant: for my next trick, I sort of re-did the distro-publisher code.
[07:40] <wgrant> So I saw!
[07:40] <wgrant> Well.
[07:41] <wgrant> I saw the "diff too big" warning in the email.
[07:41] <wgrant> I've not seen the change itself.
[07:41] <wgrant> Similar to what you did to process-accepted?
[07:41] <jtv> "Diff too big"?  I hadn't seen that.
[07:41] <jtv> Should be "only" 1200 lines or so.
[07:41] <jtv> I suppose.
[07:42] <jtv> I didn't feel I could just go on adding to the problem.
[07:42] <wgrant> Indeed.
[07:42] <wgrant> So much evil to destroy :(
[07:43] <jtv> The question right now is: how do I Q/A publish-distro?
[07:43] <jtv> (Have a look at it — it wasn't nearly as hairy as it seemed)
[07:44] <wgrant> That is a lot of tests.
[07:44] <jtv> Yes, it really helps to know that the components work.
[07:45] <jtv> Found one or two cases of "this couldn't have worked."
[07:52] <jtv> hi bigjools
[07:52] <bigjools> morning
[08:10] <stub> Anyone want to review https://code.launchpad.net/~stub/launchpad/staging/+merge/68529 for me? Boring meat and potatoes staging/production rollout code.
[08:12] <mrevell> Morning
[08:27] <StevenK> wgrant: You remove a XXX from 2006 that references bug 55089
[08:27] <_mup_> Bug #55089: IUpstreamBugTask should be renamed to IProjectBugTask <lp-bugs> <tech-debt> <Launchpad itself:In Progress by wgrant> < https://launchpad.net/bugs/55089 >
[08:28] <StevenK> Ah, which is already linked. Nice.
[08:49] <stub> 1.1 billion branchrevision rows now... going up by about 50 million/month.
[09:00] <mwhudson_> stub: is the disk space reduced at all by not having id as a primary key?
[09:01] <stub> It is now that the nodes have all been rebuilt.
[09:01] <mwhudson_> ah right
[09:01] <mwhudson_> i guess it's a substantial fraction of the node rebuild time though...
[09:06] <jtv> stub: I'm still amazed by the lack of alarms and sirens for that change.
[09:07] <danilos> -back
[09:08] <danilos> -back
[09:08] <stub> mwhudson: the id column plus various indexes came to a few 10s of GB
[09:08] <danilos> whoops, wrong keyboard layout and I insist on retyping it :)
[10:09] <jml> really really starting to wish Launchpad has some kind of push notification
[10:10] <wgrant> jml: Only once you lost your ability to direct? :)
[10:10] <jml> wgrant: now I can afford to be selfish.
[10:10] <wgrant> :(
[10:10] <wgrant> Selfishness is what Launchpad has needed for a number of years now...
[10:11] <wgrant> Stakeholder direction only gets us so far in the sensible directions.
[10:11] <wgrant> We've been making it work, rather than making it not suck.
[10:11] <wgrant> :)
[10:13] <jml> wgrant: You tell me this only once I've lost my ability to direct? :P
[10:13] <wgrant> Heh
[10:13] <nigelb> heh, so hire someone who's as selfish as you  :D
[10:41] <wgrant> danilos: Thanks for organising that deployment!
[10:47] <nigelb> jml: communicating internally in the open is not a bad thing. I like reading the list even though I may not be able to do anything for a few items.
[10:54] <danilos> wgrant, hey, you are welcome :)
[10:54] <danilos> wgrant, and it should be more of a norm for the rest of us to do it
[11:29] <stub> allenap: https://code.launchpad.net/~stub/launchpad/staging/+merge/68529 :-)
[11:30] <allenap> stub: I'm already looking at it :)
[11:30] <allenap> stub: Out of interest, why did you go for using /etc/init.d/pgbouncer instead of using PAUSE/SUSPEND/RESUME via the pgbouncer virtual database?
[11:32] <stub> allenap: We need to shutdown pgbouncer because suspend/resume just blocks inbound connections, not reject them.
[11:33] <stub> allenap: There is an option to tell it to reject connections that can't connect after x seconds, but it doesn't work in suspend mode (either bug or design, don't know)
[11:34] <stub> allenap: in the lightning talk I gave, I sketched out a situation where connections block but after further discussions with lifeless we are just going to drop them and require the clients to cope and/or present nice errors to the users.
[11:34] <allenap> stub: Okay. The init script does cause a pause then shutdown, but with only 1 second delay. Is that okay.
[11:34] <allenap> ?
[11:36] <stub> allenap: That is fine.
[11:36] <allenap> stub: r=me
[11:36] <stub> And I could shut it down by other means (psql -d pgbouncer -c shutdown, or kill(1)) if it becomes a problem.
[11:36] <stub> ta
[11:39] <danilos> jtv1, rvba: hi, there are a few revisions of your needing QA, it'd be nice if you can get to that today
[11:39] <jtv1> danilos: I know, thanks
[11:39] <danilos> yours
[11:39] <rvba> danilos: will do.
[11:45] <rvba> danilos: done.
[11:45] <danilos> rvba, thanks
[12:46] <jtv1> allenap: free for a review?  https://code.launchpad.net/~jtv/launchpad/get_derived_distros/+merge/68675
[13:02] <deryck> Morning, all
[13:27] <jcsackett> allenap: can i request a review for https://code.launchpad.net/~jcsackett/launchpad/a-private-place-to-live/+merge/68687?
[13:30] <allenap> jcsackett: Sure. I think jtv's first then you.
[13:30] <jtv> allenap: I've been producing them faster than you can review them.  :)
[13:30] <jcsackett> allenap: works for me. i can always do jtv's if you haven't already started. just can't review my own branch. :-P
[13:31] <jtv> jcsackett: I have a few more ready now.
[13:31] <jtv> So there's enough for both of you!
[13:31] <jcsackett> jtv: erm, eh, fantastic? :-p
[13:31] <jtv> hehheh
[13:31] <allenap> jcsackett: Okay, you start with jtv, I'll do yours, then move back onto jtv's new ones.
[13:31] <jcsackett> allenap: righto.
[13:40] <jcsackett> jtv: r=me on the first one.
[13:40]  * jcsackett likes short diffs.
[13:40] <jtv> thanks!
[13:41] <jcsackett> jtv: you have a preferred next branch for me to look at? i see three in the queue.
[13:41] <jtv> Yes: the bug-788078 one, thanks.
[13:42] <jtv> That's bigger, but I carved out pieces for a separate branch — which you just reviewed.  :)
[13:42] <jcsackett> jtv: ok. looking at that one momentarily.
[13:43] <jtv> Thanks.
[14:19] <sinzui> allenap, jcsackett: are either of you looking at https://code.launchpad.net/~wallyworld/launchpad/picker-wiring-812255/+merge/68629
[14:19] <jcsackett> sinzui: it's in the queue. :-)
[14:20] <allenap> sinzui: What Jon said :)
[14:22] <nigelb> oh, 2 reviewers today! perfect day to get my branch out.
[14:32] <bac> allenap: could you review https://code.launchpad.net/~bac/launchpad/bug-799901/+merge/68590 at your leisure?
[14:33] <allenap> bac: Sure :)
[14:35] <jcsackett> jtv: correct me if this is wrong, but it looks like this adding a fair bit of new iteration to the process; is this script not one we worry about time to complete on?
[14:35] <nigelb> ugh, I need some help with a branch. Does anyone have a few minutes to help figure out why I'm getting http://dpaste.com/573320/ for https://code.launchpad.net/~nigelbabu/launchpad/spec-sub-sort/+merge/63315
[14:36] <jtv> jcsackett: only for Ubuntu, in which case the list it iterates over is of length 1.
[14:36] <allenap> nigelb: I'll take a look.
[14:36] <nigelb> allenap: Thanks a bunch!
[14:36] <jtv> jcsackett: the idea is we can do the work for all _other_ distros we do it for much more quickly.
[14:36] <jcsackett> jtv: so if we're doing all-derived we're well aware it could take a bit and that's just fine?
[14:36] <jcsackett> jtv: ok.
[14:36] <jtv> Yes.  If it's not, we can easily extend this to more fine-grained load-balancing, such as "publish a thru f on this server."
[14:37] <jcsackett> jtv: ah, yes, you mentioned granularity in the cover letter.
[14:37] <jtv> Thought so.  :)
[14:37] <jcsackett> ok, jtv, r=me. just wanted to make sure i wasn't approving a performance bomb. :-)
[14:37] <jtv> Good job.  Thanks!
[14:38] <bigjools> cody-somerville, timrc: do you have time to talk about OEM's ongoing requirements with regard to our derived distros feature?
[14:38] <timrc> bigjools, if I could keep natty from crashing, yes :)
[14:38] <cody-somerville> bigjools, When?
[14:39] <bigjools> can you do it in the next hour or so?
[14:39] <timrc> next week would probably be better as cody-somerville will be back in North America
[14:39] <bigjools> or now? :)
[14:39] <timrc> oh..
[14:39] <jcsackett> allenap: thanks for your comments, i'll address those changes. how much longer are you on review for?
[14:39] <bigjools> next week is ok if that's better
[14:39] <cody-somerville> bigjools, I'm at DebCamp this week. Next week would be much better for me.
[14:40] <allenap> jcsackett: Another couple of hours, then I'll be back later this evening.
[14:40] <jcsackett> allenap: ok. thanks.
[14:40] <bigjools> cody-somerville, timrc: ok that's fine.  I want to see how attached you are to using those crazy custom suites :)
[14:40] <allenap> jcsackett: I think you only *need* to address point 3.
[14:40] <timrc> bigjools, we're more crazy about deriving distros from multiple sources I think :) can we do that yet?
[14:41] <bigjools> timrc: yes
[14:41] <jcsackett> allenap: right, but if i can i'll address the others. no reason to delay good fixes if it's not out of scope.
[14:41] <bigjools> it's not quite released yet but we got it working finally, today
[14:42] <timrc> bigjools, neat!
[14:43] <cjwatson> what's the best way to submit a set of proposed changes for the Launchpad PPA?
[14:43] <cjwatson> I guess I need to do them for all of lucid, maverick, natty :-/
[14:43] <bigjools> cjwatson: if you have packages in a different PPA we can review and copy
[14:44] <cjwatson> I do (well, mvo does), but only for lucid at the moment
[14:44] <bigjools> well it's your fault, you keep releasing new series every 6 months :)
[14:44] <cjwatson> gosh, I never knew I had a choice. :-)
[14:45] <cjwatson> ok, I'll see if I can put together a staging PPA with everything
[14:45] <bigjools> great
[14:53] <nigelb> hrm, is subscribing to a blueprint broken on trunk?
[14:54] <nigelb> s/trunk/devel
[14:54] <nigelb> I just realized I can't subscribe to a blueprint on my dev env.
[14:57] <allenap> nigelb: It should read user=subscribed_by not user=user.
[14:57] <allenap> Line 567 of specification.py.
[14:58] <nigelb> ah
[14:59] <nigelb> I think I didn't notice it when "fixed" the merge conflict when I merged from devel the last time
[15:08] <allenap> nigelb: On the one hand sort_for_display() is generic - it can sort by any attribute - on the other it calls .lower() on the value it finds. I think you'd be better off without it; just fix the bug in specification.py and don't worry about the general case. As jtv notes in his review, it's a much bigger problem. What we really need is an agreed way to derive a collation key, but that's out of scope for this fix.
[15:09] <jtv> Isn't sort_for_display exactly what should hide that problem from us, so we can fix it once?
[15:09] <nigelb> allenap: The inital bug was there was no lower() cuasing the sorting to be messed up.
[15:09] <nigelb> what jtv just said.
[15:10] <jtv> I am so sorry for opening this whole can of worms...  :)
[15:10] <nigelb> hehe
[15:10] <allenap> jtv: Not really, because it conflates sorting with getting a collation key.
[15:12] <jtv> Unfortunately, yes.  But at least it will mark places where we tried to work around this!
[15:12] <nigelb> ugh, bigger traceback. http://dpaste.com/573346/
[15:12] <nigelb> If you could help me figure out how to start lookig at zope traceback, I'd be very grateful.
[15:14] <bigjools> nigelb: line 156 is the clue
[15:17] <nigelb> hm, so I look at that template?
[15:20] <bigjools> nigelb: it's telling you where the traversal failed
[15:20] <bigjools> in view/sorted_subscriptions
[15:20] <nigelb> ah
[15:21] <nigelb> so I look at browser/specificationsubscription.py where sorted_subscriptions is seems to be defined
[15:21] <allenap> jtv, nigelb: There is already an agreed upon collation key function for people: lp.registry.model.person.person_sort_key
[15:28] <nigelb> allenap: Oh.
[15:28]  * nigelb headdesks and rewrites.
[15:29] <allenap> nigelb: Hehe, don't worry, it's well hidden :)
[15:33] <allenap> nigelb: Fwiw, here's a diff of the changes I would make: http://paste.ubuntu.com/649234/
[15:34] <nigelb> allenap: thanks!
[15:35] <allenap> jcsackett: By the way, would you have time to review a branch of mine? https://code.launchpad.net/~allenap/launchpad/localpackagediffs-filter-by-package-set-bug-809786-overlay/+merge/68647
[15:36] <jcsackett> allenap: as it happens, i would. :-)
[15:36] <allenap> jcsackett: Thanks :)
[15:47] <nigelb> allenap: I can't import person_sort_key.
[15:47] <nigelb> "ImportError: cannot import name person_sort_key"
[15:48] <allenap> nigelb: Yeah, there appears to be a circular import problem. In my diff I import it near where it's used and that works.
[15:48] <nigelb> allenap: ah, but I also need to use it in 225-ish
[15:49] <allenap> nigelb: Yeah. See my diff :)
[15:49] <nigelb> ah, right. Sorry.
[15:49] <nigelb> I should learn to read :P
[15:59]  * nigelb grrs.
[15:59] <nigelb> No traceback. But no worky either.
[15:59] <allenap> nigelb: Push your branch and I'll take another look.
[16:08] <LPCIBot> Project db-devel build #741: FAILURE in 5 hr 40 min: https://lpci.wedontsleep.org/job/db-devel/741/
[16:09] <nigelb> allenap: pushed :)
[16:11] <jcsackett> allenap: are you planning on filing bugs for all these xxx's with "bug=???" ?
[16:12] <allenap> jcsackett: I suppose so... the sneaky part of my mind had tried to forget about that :)
[16:12] <jcsackett> allenap: if you'll file those bugs and update the XXX, r=me. i can go ahead and approve it now with that understanding. :-)
[16:13] <allenap> jcsackett: Thanks, that's awesome.
[16:13] <jcsackett> allenap: that's a nice trick with the auto re-aligning of the overlay, btw. i wonder why that's not default behavior.
[16:13] <allenap> jcsackett: I'll do the same with your review.
[16:14] <jcsackett> oh, thanks.
[16:27] <allenap> nigelb: Right, so is it not ordering correctly in the UI?
[16:28] <nigelb> allenap: no.
[16:31] <allenap> nigelb: SpecificationPortletSubcribersContents.sorted_subscriptions returns the subscriptions that can be unsubscribed by the user before those that the user cannot. Could that explain what you're seeing?
[16:35] <allenap> nigelb: I have to go very soon, but I'll be back later (at ~1900 UTC). I've subscribed to your branch so just update the mp with your notes and I'll take a look.
[16:35] <nigelb> allenap: I'll do that :)
[17:15] <nigelb> allenap: You were right. That's what I was seeing.
[17:40] <bac> thanks for the review allenap -- nice suggestions
[18:35] <timrc> I have a user asking what the contents of  /etc/pkgbinarymangler/striptranslations.conf looks like for one of our P3A's -- can anyone assist with that, here?
[19:02] <allenap> bac: Cool, np.
[19:03] <allenap> nigelb: That's cool. I reckon your branch is nearly ready to land. If you incorporate the minor changes to the test I put in the diff I reckon it will be ready.
[19:20] <LPCIBot> Project devel build #908: FAILURE in 5 hr 39 min: https://lpci.wedontsleep.org/job/devel/908/
[19:22] <nigelb> allenap: yeah, doign that now.
[19:30] <nigelb> allenap: pushed :)
[19:41] <lifeless> morning
[19:43] <lifeless> cjwatson: stuff for the lp ppa? we only realy care about about lucid, natty and oneiric atm
[19:43] <allenap> nigelb: I'll land it for you.
[19:45] <nigelb> allenap: thanks! Also thanks for hand-holding through this :)
[19:47] <allenap> nigelb: No worries, thanks for taking the time to do this. It's making Launchpad better.
[19:47] <nigelb> allenap: Yeah, talking to jml at UDS helped a huge deal in getting off my mental block about patching launchpad :)
[19:49] <allenap> nigelb: jml's UDS seems to have been a big success. It's hard getting started on Launchpad, but I think it's rewarding; we should be able to release your fix tomorrow or Monday.
[19:50] <nigelb> yay :)
[19:50] <nigelb> Now I need to find out a way to have wallyworld's working hours and my awake hours and my free hours all to fall into the same slot.
[19:51]  * cody-somerville recommends a time machine.
[19:51] <allenap> cody-somerville: OEM's working on one of those, right?
[19:51] <cody-somerville> I'm not at liberty to say, sorry.
[19:54] <lifeless> sure you, just remember to go back in time and stop him asking about it
[19:57] <nigelb> haha
[20:01] <allenap> nigelb: Your branch should land in a few hours once the full test suite has run. I'll check on it in the morning. I'm off now, cheerio.
[20:03] <nigelb> allenap: laters! thanks again!
[20:54] <cjwatson> lifeless: no maverick?  ok, that simplifies things a bit
[20:55] <cjwatson> though actually a bit late since I already did those backports :-)
[20:55] <cjwatson> oh well, will post things from debconf
[20:59] <lifeless> cjwatson: its nice to have, but no dev uses it and we don't deploy on it
[21:01] <cjwatson> ok
[21:04] <lifeless> things that go on biuldds obviously need to support all the flavours buildds do
[21:04] <lifeless> but IIRC this isn't one of those
[21:04] <cjwatson> indeed not
[21:33] <wgrant> lifeless: Yeah, this is just getting rid of the interfaces, as it was big enough.
[21:34] <wgrant> lifeless: I plan to extract most of the target-specific stuff from lp.bugs.
[21:34] <wgrant> Because it is pretty revolting.
[21:43] <LPCIBot> Yippie, build fixed!
[21:43] <LPCIBot> Project db-devel build #742: FIXED in 5 hr 35 min: https://lpci.wedontsleep.org/job/db-devel/742/
[21:49] <wgrant> sinzui: But won't a productseries milestone vocab only show milestones within that series, which is what we want here?
[22:06] <sinzui> wgrant, I think that is what I am trying to understand. a  productseries should only target to a milestone that belongs to a series. a product bug could be targeted to any milestone for any series
[22:07] <sinzui> wgrant, there is not thing wrong with what you did. I just want to know WTF Lp thinks it is doing
[22:09] <sinzui> It will all be moot when we simplify bugtasks to series. This vocab will be forced to have similar rules
[22:09] <wgrant> sinzui: Right.
[22:10] <wgrant> I feel that we should probably preserve existing behaviour for now.
[22:10] <wgrant> This pipeline will already extend into 5 or 6 branches.
[22:10] <sinzui> absolutely keep it the way it is. I just wanted to know if we know about this bug. Maybe it needs to be reported
[22:16] <wgrant> Yeah.
[22:16] <wgrant> Ah, you've approved it now. Thanks!
[22:26] <wgrant> wallyworld: Should bug #806785 be closed?
[22:26] <_mup_> Bug #806785: Person picker displays duplicate info when selecting recipe owner <disclosure> <picker> <Launchpad itself:In Progress by wallyworld> < https://launchpad.net/bugs/806785 >
[22:27] <wallyworld> wgrant: yes,. i believe so. i'll check. perhaps i didn't link to to the branch
[22:27] <wgrant> It's linked, but maybe wasn't until too late.
[22:27] <wallyworld> i would have linked it before i did the mp
[22:27] <wgrant> jtv: https://lpbuildbot.canonical.com/builders/lucid_db_lp/builds/1171/steps/shell_6/logs/summary <- I think your ArchiveCruftChecker refactoring might have made it spew crufty to stderr?
[23:22] <wgrant> Argh.
[23:22] <wgrant> Series tasks.
[23:23] <lifeless> they will all be at some point
[23:23] <wgrant> Yeah, but the current implementation is a bit unfortunate.
[23:23] <wgrant> In particular, you can presently change the sourcepackagename of a series sourcepackage task through the web UI.
[23:24] <wgrant> Probably want to forbid that.
[23:25] <wgrant> (I'm working on pushing all target changes through transitionToTarget, which doesn't let you change to/from a series target, because that's what nominations are for)
[23:26] <wgrant> Hmm, retargetting them breaks the UI a bit.
[23:26] <wgrant> If there's no corresponding DSP task, the name is not shown at all.
[23:26] <wgrant> lifeless: Any opinions?
[23:28] <lifeless> uhm
[23:28] <sinzui> StevenK, lp:~sinzui/launchpad/dsp-picker-fields
[23:28] <lifeless> so big picture
[23:29] <lifeless> we want users that have sufficient privilege to just move stuff around willy nilly
[23:29] <lifeless> e.g. same-series different-sourcepackagename is a no-brainer change to permit everyone
[23:29] <wgrant> The current model makes that hard, but when everything is a series task it will be easier.
[23:30] <wgrant> SP tasks are not meant to exist without a corresponding DSP task.
[23:30] <wgrant> The UI breaks.
[23:30] <lifeless> we want users that have insufficient privilege to have to go through a handshake - the nomination process - for changes they are not permitted
[23:31] <lifeless> wgrant: SP being DSSP really ?
[23:31] <wgrant> lifeless: Right.
[23:31] <lifeless> this sound slike a conjoined masterish thing
[23:31] <lifeless> anyhow
[23:31] <wgrant> Similar.
[23:32] <lifeless> I have no particular opinion; I'd like that we move towards the big picture
[23:32] <lifeless> I'd prefer we don't let broken things happen
[23:33] <lifeless> if we permit something that breaks the model today, I have no objection to restricting it
[23:33] <lifeless> I'd question restricting something that isn't restricted today.
[23:34] <lifeless> (and doesn't cause breakage)
[23:34] <wgrant> I haven't seen any breakage around (except for really old bugs like bug #43150), so I presume it's not done much or at all.
[23:34] <_mup_> Bug #43150: [SRU] maxima frontends fail to connect <wxmaxima (Ubuntu):Fix Released> <gcl (Ubuntu Dapper):Fix Released by wgrant> <maxima (Ubuntu Dapper):Fix Released> < https://launchpad.net/bugs/43150 >
[23:35] <sinzui> wallyworld, http://www.jslint.com/lint.html
[23:39] <wgrant> lifeless: It is tempting to forbid it, and if someone complains then chastise them and potentially hack transitionToTarget to permit changing to another SP in the same DS.
[23:43] <lifeless> does it break things no matter what ?
[23:43] <lifeless> or does it break things under some circumstances only ?
[23:43] <wgrant> Unless you change all of them at once.
[23:45] <wgrant> Meh, for now I will special-case permit it.