[02:11] <thumper> ?!?!?!
[02:11] <thumper> line 765 of client.js
[02:12] <thumper> WTF
[02:27]  * thumper heads for a real coffee
[02:58] <lifeless> [02:58] <lifeless>     Hard / Soft  Page ID
[02:58] <lifeless>      129 /  293  BugTask:+index
[02:58] <lifeless>       61 /  196  Distribution:+bugs
[02:58] <lifeless>       56 / 4821  Archive:+index
[02:58] <lifeless>       28 /   44  Branch:+index
[02:58] <lifeless>       12 /    3  Person:+related-software
[02:58] <lifeless>       11 /    2  Product:+filebug-show-similar
[02:58] <lifeless>        9 /    2  Distribution:EntryResource
[02:58] <lifeless>        8 /   29  MailingListApplication:MailingListAPIView
[02:58] <lifeless>        8 /    3  Cve:+index
[02:58] <lifeless>        6 /  156  POFile:+translate
[03:39]  * thumper has a bad feeling about this
[03:40] <thumper> lifeless: when was the last rollout?
[03:41] <wgrant> thumper: 24th
[03:41] <wgrant> 12248
[03:42] <wgrant> 12263 should happen once mthaddon wakes up.
[03:42] <thumper> no
[03:42]  * thumper slams the breaks on it
[03:42] <wgrant> Why?
[03:42]  * thumper raises the red flag
[03:42] <thumper> wgrant: try editing a bug description in qastaging
[03:43] <wgrant> Timeout?
[03:43] <thumper> no
[03:43] <thumper> oops
[03:44] <thumper> ValueError: Unicode results must have a text content type.
[03:44] <thumper> in the zope publisher
[03:44] <thumper> I'm trying to figure out why
[03:44] <thumper> I thought it was just local for me
[03:44] <thumper> due to me messing around
[03:44] <wgrant> I get a timeout :/
[03:44] <thumper> but after I removed all my changes
[03:44] <thumper> it still oopses
[03:44] <thumper> so I checked qastaging
[03:45] <wgrant> Sigh.
[03:45] <wgrant> lp-oops.c.c can only see up to QS1.
[03:46] <thumper> I've just emailed lp-dev
[03:47] <wgrant> Have you tried downgrading lazr.restful?
[03:49] <thumper> not yet
[03:50] <wgrant> That's a really strange error.
[03:52] <thumper> yes, it is
[03:53] <wgrant> I wonder if Windmill would have caught this.
[03:53] <thumper> probably
[03:54] <thumper> actually, I think it is something I did
[03:54] <thumper> last week
[03:54]  * thumper thinks
[03:54] <wgrant> The Windmill tests were passing OK before lazr.restful 0.15.3, I believe.
[03:54] <wgrant> Hmm.
[03:54] <wgrant> Not lazr.restful.
[03:55] <thumper> hmm....
[03:55] <wgrant> Still broken with 0.15.0.
[03:55] <thumper> wgrant: same error?
[03:55] <wgrant> Yes.
[03:55] <thumper> (Pdb) content_type
[03:55] <thumper> 'application/xhtml+xml'
[03:55] <thumper> the publisher expects it to start with 'text/'
[03:55] <wgrant> Hah.
[03:55] <thumper> I changed something...
[03:55] <thumper> but
[03:56] <thumper> it shouldn't have changed
[03:56] <thumper> this
[03:56] <lifeless> thumper: when you get a gap, filing a bug to change the exception to show the wrong type would be helpful.
[03:56] <wgrant> What did you change? The webservice named adapters thing?
[03:56] <thumper> lifeless: it is in the zope publisher code
[03:56] <thumper> wgrant: yeah
[03:56] <lifeless> thumper: yes
[03:56] <lifeless> thumper: thus filing a bug rather than changing it in the first instance
[03:56] <thumper> but this is asking for the representation of the description
[03:57] <thumper> which "should" have the same implementation
[03:57] <thumper> I wonder if the resulting content type has changed....
[03:57] <thumper> we should be able to test this...
[03:57] <lifeless> on qastaging
[03:57] <lifeless> SELECT heat\n FROM Bug, Bugtask, Product\n WHERE Bugtask.bug = Bug.id\n AND Bugtask.product = Product.id\n AND Product.project IS NOT NULL\n AND Product.project = 82\n ORDER BY Bug.heat DESC LIMIT 1'<br /> Parameters:()<br /> Original error: QueryCanceledError('canceling statement due to statement timeout\n'
[03:59] <lifeless> thumper: bug editing works fine on qastaging in the web ui
[03:59] <lifeless> thumper: could it be your client asking for something odd?
[03:59] <thumper> lifeless: it didn't for me
[03:59] <lifeless> https://bugs.qastaging.launchpad.net/launchpad-foundations/+bug/1234 - edit it using the ui
[03:59] <_mup_> Bug #1234: Gina is an unmaintainable mess of command line options, environment variables and shell scripts <lp-foundations> <Launchpad itself:Fix Released by debonzi> < https://launchpad.net/bugs/1234 >
[04:00] <thumper> OOPS-1852QS15
[04:00] <wgrant> I used that very bug.
[04:00] <wgrant> It broke.
[04:00] <lifeless> wgrant: timeout getting heat for the project gourp
[04:00] <wgrant> Oh.
[04:00] <wgrant> So it was.
[04:00] <lifeless> I've now edited it three times without trouble
[04:00] <thumper> OOPS-1852QS16
[04:00] <wgrant> devpad has the OOPS now.
[04:01] <wgrant> devpad doesn't have QS16 :(
[04:01] <thumper> that was my oops for trying to edit it
[04:01] <lifeless> thumper: using the web UI ?
[04:01] <thumper> yes
[04:01] <lifeless> thumper: just now, or before ?
[04:01] <thumper> just now
[04:01] <lifeless> thumper: this is odd, if you refresh you'll see i've edited it
[04:01] <thumper> lifeless: which browser
[04:01] <lifeless> chrome
[04:02] <wgrant> Chromium 8.blahblah here.
[04:02] <lifeless> chromium 8.0.552.224 (685999)
[04:02] <lifeless> I'll try ff
[04:02] <thumper> lifeless: not the title
[04:02] <thumper> lifeless: the description
[04:02] <lifeless> bah
[04:02] <lifeless> ok
[04:02] <lifeless> OOPSes for me
[04:03] <lifeless> you're not crazy
[04:03] <wgrant> thumper: Which adapters did you change?
[04:03] <wgrant> I know you changed person.
[04:03] <wgrant> But did you also change TextField or whatever it is?
[04:04] <lifeless> wow, 300ms to get hottest heat for a project gorup
[04:04] <thumper> wgrant: yes, I changed Text
[04:04] <lifeless> -slow-
[04:04] <wgrant> Ah, yes.
[04:04] <thumper> wgrant: but it does the same thing
[04:05] <wgrant> So it does.
[04:05] <thumper> wgrant: it appears to  be the content type
[04:05] <thumper> that is the problem
[04:05] <thumper> not the rendering of the description
[04:05] <thumper> I wonder if there was a lazr restful change that played with the content type
[04:05] <thumper> it isn't something I remembered from last week
[04:05] <wgrant> Except that it still dies with lazr.restful 0.15.0.
[04:05] <thumper> really?
[04:05] <thumper> WTF?
[04:05] <wgrant> It was the first thing I tried. Let me try again.
[04:06] <lifeless> bisect time ?
[04:06] <wgrant> Done already.
[04:06] <wgrant> It's 12251, as expected.
[04:06] <wgrant> Going further into the diff now.
[04:06] <wgrant> But first trying lazr.restful again...
[04:06] <wgrant> Also, our appserver startup time fucking sucks.
[04:06] <lifeless> tagging it bad
[04:06] <wgrant> Death to ZCML, etc.
[04:06] <lifeless> it does
[04:07] <lifeless> ok, https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html should notice in a few minutes
[04:07] <wgrant> thumper: Confirmed bad with lazr.restful 0.15.0.
[04:07] <wgrant> Something in the r12251 diff is somehow breaking it.
[04:07] <lifeless> I'll send a rollback for this now
[04:07] <wgrant> But I cannot see how.
[04:07] <wgrant> Be careful.
[04:07] <wgrant> There was a later lazr.restful update.
[04:08] <lifeless> wgrant: ><
[04:08] <wgrant> You cannot roll it back safely without going through ec2.
[04:08] <lifeless> wgrant: right
[04:08] <lifeless> ok, actually, its past EOD
[04:08] <lifeless> so I won't do it
[04:08] <lifeless> as theres no chance I'll  be paying attention later
[04:09] <thumper> yeah... that isn't easy to revert
[04:09] <thumper> as there are later revisions tweaking it
[04:09] <wgrant> thumper: Have you tried bypassing the JS?
[04:09]  * thumper pokes
[04:09] <thumper> wgrant: yes
[04:09] <wgrant> What happens?
[04:10] <thumper> well... for the entry, it is working fine
[04:10] <thumper> hmm....
[04:10] <thumper> maybe not
[04:11]  * wgrant compares the requests.
[04:11] <thumper> I remember testing this though :(
[04:11] <thumper> it was one of the things we tested to make sure we didn't fuck it up
[04:13] <wgrant> Well, the requests are identical, so it's not JS, so it is debuggable.
[04:13]  * thumper stops...
[04:13] <thumper> and thinks
[04:13] <thumper> the publisher has the correct string
[04:13] <thumper> I can see that in the debugger
[04:13] <thumper> but it is trying to return a different content type
[04:14] <wgrant> But I cannot see how.
[04:16] <wgrant> thumper: In both cases the Accept says application/xhtml+xml.
[04:16] <wgrant> Huh.
[04:16] <wgrant> In the good case it also returns application/xhtml+xml.
[04:17] <wgrant> So the content type is right.
[04:17] <thumper> which good case?
[04:17] <wgrant> 12250, before the problematic revision.
[04:17] <wgrant> It asks for application/xhtml+xml, and gets it back fine.
[04:17] <wgrant> The publisher does not choke.
[04:18] <wgrant> Er.
[04:18]  * wgrant headdesks.
[04:18] <wgrant> I just looked at the adapter diff.
[04:18] <wgrant> Now it is pretty obvious.
[04:18] <wgrant> You removed the .encode('utf-8')
[04:19]  * wgrant tries.
[04:20] <thumper> wgrant: we checked that
[04:20] <wgrant> It works fine with that readded.
[04:20] <thumper> :((
[04:20] <thumper> the lazr.restful code was encoding it
[04:20] <wgrant> Huh.
[04:20] <thumper> we thought we were double encoding
[04:21] <thumper> lazr.restful gets all the results and encodes that
[04:22] <thumper> argh...
[04:22]  * thumper thinks...
[04:22] <thumper> the multiline editor asks for a xhtml+xml representation of a single field of the resource
[04:23] <thumper> which would go through a different code path
[04:23] <wgrant> Right.
[04:23] <thumper> to the one what asks for the entire entry
[04:23] <wgrant> Ah, indeed.
[04:23] <thumper> which is what the chooser needs
[04:23] <wgrant> So the entry gets encoded by lazr.restful.
[04:23] <wgrant> But the field does not.
[04:23] <thumper> I think so
[04:23] <thumper> but the field should
[04:23] <wgrant> It should.
[04:23] <wgrant> Let's see what lazr.restful thinks...
[04:23]  * thumper goes to dig in lazr.restful
[04:25] <wgrant> Hmm.
[04:25] <wgrant> Interesting.
[04:27] <wgrant> It looks like we just need to fix EntryFieldResource._representation to encode if it is a unicode?
[04:28] <wgrant> I guess that whatever tests it uses an adapter that returns a str.
[04:28] <wgrant> Although EntryFieldResource has no direct tests.
[04:30] <thumper> I guess
[04:30]  * thumper tries
[04:30]  * wgrant is already waiting for the appserver to start...
[04:30] <wgrant> Seems to work OK.
[04:31] <thumper> wgrant: yeah...
[04:32] <wgrant> Both entry and field representations looks fine now.
[04:32] <thumper> wgrant: if you see the EntryResource._representation it encodes utf-8
[04:32] <wgrant> It does.
[04:32] <thumper> although
[04:32] <wgrant> Hmm.
[04:32] <wgrant> Interesting.
[04:33] <wgrant> There is a difference in the HTML entry repr.
[04:33] <thumper> I'm wondering if the EntryFieldResource._representation is called from EntryResource...
[04:33] <wgrant> It doesn't seem like it.
[04:33] <wgrant> I'll throw some Unicode in and see.
[04:33] <wgrant> duplicate_of_link in dev is the empty string, but on lpnet it's 'None'.
[04:33] <wgrant> (this is in the HTML entry representation, as seen in the browser)
[04:34] <wgrant> I suppose that's the new reference formatter.
[04:34] <wgrant> It's not being double-encoded.
[04:34] <lifeless> ok, I'm really EOD, have to cook dinner etc etc etc
[04:34] <wgrant> So it looks like EntryResource doesn't uses EntryFieldResource.
[04:35] <lifeless> if you need me, SMS and I'll come a running
[04:35] <wgrant> https://bugs.launchpad.dev/api/devel/bugs/1 has a nice snowman, and so does the webapp after changing it.
[04:35] <_mup_> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <metacity:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubuntu:I
[04:36] <wgrant> thumper: I suppose we should wait for a Leonard, though :(
[04:36]  * thumper checks something
[04:39] <thumper> :(
[04:40] <thumper> something seems weird
[04:40] <wgrant> ?
[04:40] <thumper> hmm... maybe not
[04:40] <thumper> https://bugs.launchpad.net/api/devel/launchpad/+bug/1234?ws.accept=application/xhtml%2Bxml
[04:40] <_mup_> Bug #1234: Gina is an unmaintainable mess of command line options, environment variables and shell scripts <lp-foundations> <Launchpad itself:Fix Released by debonzi> < https://launchpad.net/bugs/1234 >
[04:41] <thumper> I would have thought that would have the description in it
[04:41] <wgrant> thumper: That's the BugTask.
[04:41] <wgrant> s@launchpad/+bug@bugs@
[04:41] <thumper> oh yeah
[04:42] <thumper> ok
[04:42] <thumper> that seems to work fine
[04:44]  * thumper puts up a lazr.restful branch
[04:47] <thumper> just running the tests
[04:48] <thumper> omg
[04:48] <thumper> it is building otu
[04:48] <wgrant> Heh.
[04:54] <thumper> wgrant: I don't suppose the tests pass for you on lazr.restful?
[04:54] <thumper> wgrant: I get 4 errors and 1 failure
[04:55] <thumper> wgrant: I did get errors in the setup of  RestrictedPython-3.6.0
[04:57] <wgrant> thumper: Let me run buildout and see.
[04:57] <wgrant> ugh, I don't have my usual buildout global download cache config here.
[04:57] <wgrant> This could take a while.
[04:59] <thumper> I'm getting the same errors with trunk
[05:00] <wgrant> Sounds fine, then.
[05:01] <thumper> we could patch the lazr.restful egg
[05:01] <thumper> or create an egg with the fix
[05:01] <thumper> land that
[05:01] <thumper> and wait for confirmation
[05:01] <thumper> for inclusion in trunk
[05:01] <thumper> wgrant: what do you think?
[05:02] <wgrant> I don't know. I'm wary about patching it, although it seems safe.
[05:02] <wgrant> It is tempting to just wait for leonard to appear and release 0.15.4 with the fix.
[05:02] <wgrant> That's not too far off.
[05:02]  * thumper frowns
[05:03] <thumper> the unmerged revisions on the code review looks crackful
[05:03] <wgrant> I don't know lazr.restful well enough to make a sensible judgement here.
[05:03] <wgrant> it is, yes.
[05:03] <thumper> the diff is right
[05:03] <thumper> I think someone "fixed" it
[05:03] <wgrant> I suspect jtv's BranchRevision changes broke it.
[05:03] <thumper> :(
[05:03] <wgrant> But I didn't end up having time to investigate.
[05:03] <wgrant> And I'm not here today.
[05:03] <thumper> wgrant: heh
[05:03] <wgrant> But he changed the relevant method, so I think that's probably it.
[05:04] <thumper> I'll flick this leonards way and get him to release the fix if it is
[05:04] <wgrant> Thanks.
[05:05] <wgrant> Hopefully it will be deployable some time tomorrow.
[05:05] <wgrant> As for the unmerged revisions, will you be able to investigate soonish?
[05:08] <wgrant> Bug #707808
[05:08] <_mup_> Bug #707808: Unmerged revisions list does not exclude merged revisions <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/707808 >
[05:08] <thumper> wgrant: not right now, I'm focused on recipes
[05:08] <thumper> and EOD for me now
[05:08] <wgrant> thumper: 'soonish' could include tomorrow.
[05:08] <wgrant> ie. should I look at it when I wake up tomorrow?
[05:08] <thumper> wgrant: yes, you
[05:08] <wgrant> k
[05:08] <thumper> are on a bug team :)
[05:09] <wgrant> Fair point.
[05:09] <thumper> thanks
[05:19] <StevenK> wgrant: That would be awesome
[05:27]  * StevenK bursts into flame too cool down
[05:29] <wgrant> StevenK: What would be/
[05:29] <wgrant> StevenK: Huh, it's only like 18°C down here.. what is it up there?
[05:30] <StevenK> 32
[05:30] <wgrant> Ow.
[05:30] <wgrant> It's just about perfect here.
[05:30] <wgrant> Although overcast.
[09:08] <mrevell> Hi
[09:09] <adeuring> good morning
[11:18] <danilos> sinzui, hi, it would be nice to get https://bugs.launchpad.net/bugs/707741 fixed ASAP
[11:18] <_mup_> Bug #707741: Translations export script failing. <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/707741 >
[11:25] <wgrant> The other blocker (12251) is first on my list for tomorrow.
[11:25] <wgrant> danilos: I'll also handle 707741 if nobody else has done it.
[11:25] <danilos> wgrant, right, but this is pretty critical in the sense that if I was translations team, I'd go right away and do it
[11:26] <wgrant> It's been failing for 48 hours already.
[11:26] <danilos> wgrant, which makes it even more so
[11:27] <danilos> wgrant, the fact that we are doing a very bad job watching our services is not something to brag about
[11:28] <wgrant> Indeed.
[11:45] <StevenK> thumper: When you start work, https://bugs.launchpad.net/launchpad/+bug/707919 sounds like something we fixed at the Thunderdome, if you want to comment.
[11:45] <_mup_> Bug #707919: Reassign to another project animation spins forever <Launchpad itself:New> < https://launchpad.net/bugs/707919 >
[11:49] <dpm> Bug 707741 is a big blocker for translation teams, who have started complaining. I'm not pointing the obvious, just trying to point out that it's a critical regression for the translations community
[11:49] <_mup_> Bug #707741: Translations export script failing. <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/707741 >
[12:08] <Ursinha> morning
[12:53] <leonardr> thumper or lifeless, i don't suppose you're still around
[12:53] <leonardr> i'm looking at the qastaging breakage
[13:58] <deryck> abentley, adeuring, henninge -- ping for call in 2.
[13:58] <adeuring> yes
[13:59] <abentley> deryck, pong
[14:15] <deryck> adeuring, https://launchpad.net/launchpad/+bugs?field.tag=upstream-translations-sharing
[14:28] <henninge> wow, I just closed two bugs in 10 secondsd
[14:33] <deryck> henninge, I think abentley already opened a bug about what you were talking about on the standup.  see bug 706005
[14:33] <_mup_> Bug #706005: solve the case where sharing is enabled with existing upstreams <upstream-translations-sharing> <Launchpad itself:Triaged> < https://launchpad.net/bugs/706005 >
[14:40] <henninge> deryck: yup, I added a comment to make that clear. Thanks.
[14:41] <deryck> np.  thank you
[14:44] <deryck> adeuring, abentley, henninge -- board is up to date with remaining tasks
[14:44] <adeuring> ok
[14:44] <abentley> deryck, cool.
[14:45] <abentley> deryck, also, yikes!
[14:45] <deryck> it's not that bad :-)
[14:46] <deryck> flacoste, you might be interested in that too ^^ (Orange board is updated with cards for remaining work on our story)
[14:46] <deryck> flacoste, there is a "misc" card added to track that we still need 2-3 cards for some remaining UI bits.
[14:47] <deryck> but henninge and I will nail that down in our call today
[14:57] <jcsackett> can someone review https://code.launchpad.net/~jcsackett/launchpad/branch-delete-api-702620/+merge/47449? it's some quick webservice stuff and tests.
[15:01] <deryck> henninge, ready for call when you are
[15:02] <henninge> deryck: give me a minute or two to finish this up, please
[15:03] <deryck> henninge, np.  take your time.
[15:08] <henninge> deryck: no, almost done
[15:08] <deryck> ok
[15:13] <leonardr> jcsackett, i'll review you if you'll review me
[15:13] <leonardr> https://code.launchpad.net/~leonardr/lazr.restful/encode-xhtml-field/+merge/47536
[15:14] <jcsackett> leonardr: deal.
[15:14] <leonardr> jcsackett: for context, see thumper's recent message to launchpad-dev
[15:14] <benji> salgado: do you have a minute for a UI review?
[15:16] <jcsackett> leonardr: dig.
[15:16] <salgado> benji, sure, though can it be after my lunch? I was about to break
[15:17] <benji> salgado: sure; let me know when you're back and I'll give you the info
[15:18] <salgado> will do
[15:18] <jcsackett> leonardr: what is this SNOWMAN stuff?
[15:18] <leonardr> jcsackett: it's an obvious unicode character
[15:18] <leonardr> start up python and >>> print u"\N{SNOWMAN}"
[15:19] <jcsackett> leonardr: huh. did not know that.
[15:20] <leonardr> i learned the syntax from thumper--it's v. nice because you don't have to write down the escape
[15:21] <jcsackett> yeah, i dig it.
[15:22] <leonardr> jcsackett, r=me
[15:23] <jcsackett> leonardr: the tree <<<< stuff in the MP is just because of your soon to be born merge oddness, right? i can safely just look at the pastebin diff?
[15:23] <leonardr> jcsackett: yeah
[15:23] <leonardr> do you know the best way to do this merge, btw?
[15:24] <jcsackett> leonardr: i have no idea, honestly. sounds like it could be painful.
[15:24] <jcsackett> leonardr: maybe lay out the situation in #bzr?
[15:24] <leonardr> jcsackett: reverting isn't too bad, since i've been committing a feature that's not done yet
[15:24] <leonardr> ok
[15:25] <jcsackett> leonardr: r=me. i'm requesting follow up from sinzui (who is usually fast), but if you need this ASAP grab anyone else. sorry i'm still only in mentored mode. :-/
[15:26] <jcsackett> i can also help huntdown a follow up if you need someone quick.
[15:33] <leonardr> jcsackett: quick would be good, this is blocking
[15:36] <sinzui> leonardr: I am seeing unicode in doctests. unicode often causes zope doctests to fail. We may have removed the ascii exception last week though
[15:36] <leonardr> sinzui: how do you suggest i do this?
[15:36] <sinzui> leonardr: why am I seeing unicode though. What is that? A BOM?
[15:36] <leonardr> sinzui: it's a snowman
[15:37] <leonardr> i am junking up the data with a unicode character to make sure it's properly handled
[15:37] <sinzui> lots of translations and answers tests encode the output to get \x1234
[15:38] <leonardr> i'll see if i can do that
[15:38] <sinzui> leonardr: Does this test play in the zope testrunnner?
[15:39] <leonardr> sinzui: i think so
[15:39] <leonardr> it sets up layers
[15:40] <danilos> sinzui, hi, could you please arrange for bug 707741 to be worked on asap: basically translation exports are broken, and that's something our users depend on
[15:40] <_mup_> Bug #707741: Translations export script failing. <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/707741 >
[15:40] <sinzui> oh, that might explain why that user did not get his export email
[15:43] <sinzui> leonardr: answers uses .encode('ascii', 'backslashreplace') to avoid outputting fun characters
[15:48] <bac> deryck[lunch]: is bin/jssize still needed?
[15:54] <sinzui> leonardr: you have my approval with the unicode fix. I included the section about unicode vs. zope test runner in my review.
[16:04]  * jcsackett is no longer happy with his dev environment.
[16:05] <leonardr> sinzui: having trouble getting the unicode fix to work, will ping you in a bit
[16:07] <leonardr> sinzui: basically, the result of webservice.get() is a string, and i can't get it into unicode so that i can use .encode('ascii', 'backslashreplace')
[16:08] <leonardr> whew, got it
[16:10] <sinzui> leonardr: all okay now?
[16:10] <leonardr> sinzui: i think so
[16:18] <salgado> benji, still want a UI review for your branch?
[16:19] <benji> salgado: absolutely: here's the MP for background on what the UI is for: https://code.launchpad.net/~benji/launchpad/bug-636193/+merge/46350 the two relevant screen shots are the page that links to the new page: http://i.imgur.com/R6jma.png and the new page itself: http://i.imgur.com/ExwBs.png
[16:37] <sinzui> jcsackett: where did you find the recent oops reports. I need to see staging for the last 6 hours
[16:42] <jcsackett> sinzui: i don't know how recent they were, but i found the ones i needed in devpad:/srv/launchpad.net-logs/qastaging/asuka/<DATE>/
[16:42] <jcsackett> so i assume /staging/asuka/<DATE>/ should be what you want.
[16:51] <lifeless> *yawn*, moin
[16:51] <deryck> bac, I think so.  Will gave to confirm, though.
[16:52] <deryck> bac, about to be on TL call, but will look after that.
[17:58] <salgado> benji, who's the target audience for that page? LOSAs?
[17:58] <benji> salgado: yes
[17:58] <benji> salgado: and developers
[17:59] <salgado> benji, I'm wondering if it'd make sense to show it to one of the LOSAs ans ask them if it has enough information for them to write a new rule?
[18:00] <benji> salgado: that makes sense; do you have a candidate in mind?
[18:01] <salgado> let's see if we can get someone to volunteer
[18:01] <salgado> LOSA ping?
[18:01] <Chex> salgado: hello there
[18:01] <lifeless> perhaps it should link to the LEP as wlel ?
[18:01] <lifeless> which is the docs for this
[18:02] <salgado> hi Chex!
[18:02] <salgado> Chex, I'm reviewing benji's branch which better documents feature flags and we'd like to know if you'd be willing to have a look and tell us if the new page works
[18:03] <salgado> (i.e. does it have all the info you'd need to write a new rule)
[18:03] <salgado> lifeless, is the LEP going to be kept up to date to match what's implemented?
[18:04] <lifeless> salgado: the goal is to move the list of actual flags/scopes out of it. but the conceptual and operational docs will stay there IMO
[18:05] <salgado> oh, ok, that's good
[18:05] <salgado> benji, can you do that?
[18:06] <benji> salgado: yep, I can remove the static docs for flags and scopes from the LEP
[18:07] <salgado> benji, oh, I meant linking to the LEP, but I'm sure lifeless will appreciate you removing the flags and scopes from there
[18:08] <benji> salgado: oh; I /could/ do that, but LEPs are unmaintained after implementation, and that one in particular already says things that aren't true, so linking to it seems like a bad idea
[18:09] <salgado> lifeless, ^
[18:10] <lifeless> benji: what do you propose for docs for this then?
[18:11] <lifeless> benji: (its not globally true to say LEPs are unmaintained after impl)
[18:13] <benji> How do we document things like this now?  Perhaps more importantly, for what audience are we documenting?  I /think/ LP developers will be writing new rules and the lib/lp/services/features/__init__.py docstring contains a nice (pre-existing) description of how feature flags works.
[18:14] <lifeless> benji: developers will be asking for things as they do features; losas will be changing stuff to deal with operational issues; for isntance the timeout is controlled by a feature flag
[18:14] <lifeless> benji: I think the LEP is fine as docs; sure it needs a cleanup, we can do that.
[18:14] <lifeless> benji: the docstring isn't operational-docs.
[18:15] <lifeless> perhaps it should be, but its not, and with a 8 hour overhead to improve it I don't think anyone will when dealing with a operational issue
[18:15]  * lifeless practices skepticsm
[18:15] <benji> lifeless: so link to the LEP from the info page?
[18:16] <lifeless> benji: thats what I was suggesting, yes. If you think its a bad idea don't do it :)
[18:16] <benji> I have to wonder if the LOSAs have a cache of operational documents somewhere.
[18:16] <lifeless> they do
[18:16] <lifeless> but they get stale as well
[18:19] <benji> Linking to a document that's already in a known-bad state feels wrong.  Not that I can think of anything better, but I'm +0 on silence being the best approach here (i.e., no link at all).
[18:19] <lifeless> benji: I'll get it cleaned up
[18:20] <lifeless> benji: what bits are wrong? just the speculation in the early part?
[18:22] <benji> lifeless: Unfortunately, I don't recall off the top of my head.  I'd have to re-read it to find the inacuacies, but I recall that there were some rather significant difference between the LEP and the current implementation and functionality.
[18:22] <lifeless> benji: ok, I think I know what you mean
[18:22] <lifeless> poolie described a phase space.
[18:23] <lifeless> I previously updated the lep to ensure it does describe what we have, but left the phase space in place.
[18:23] <lifeless> I'll happily remove it
[18:24] <lifeless> sinzui: hi
[18:24] <lifeless> sinzui: do you need help w/ mailman ?
[18:24] <lifeless> on qastaging
[18:24] <sinzui> yes. I do not know why QAS mailman cannot talk to QAS launchpad. we get a 403
[18:25] <benji> Chex: are you familiar with the feature flags functionality? (https://launchpad.net/+feature-rules)  I'm adding a little documentation to help when writing rules so people will know which flags and scopes are available, screen shot at http://i.imgur.com/ExwBs.png
[18:25] <benji> Chex: we'd like to know if that presentation of the info makes sense to LOSA eyes
[18:26] <benji> lifeless: ok, so I should add a link to the LEP from the info page?  (and I suppose also add a special note on the LEP that it is intended to be kept up to date with the implementation, and also a note in the implementation that when it is changed the LEP should be updated)
[18:27] <lifeless> benji: I don't think we need a special note; LEPs that no longer reflect reality are harmful
[18:27] <lifeless> benji: I thought our standard practice was to keep things up to date
[18:28] <lifeless> e.g. gary has been updating things
[18:28] <lifeless> and so have other people
[18:28] <benji> 11:11 < benji:#launchpad-dev> are LEPs meant to be kept up to date after they're implmented or are they simply historical?
[18:28] <benji> 11:18 < flacoste:#launchpad-dev> benji: historical
[18:28] <lifeless> flacoste: ^ lets talk about this ;)
[18:28] <benji> lifeless: ^^ there seems to be some confusion on that front
[18:33] <bac> hi deryck, could i talk to you sometime today with some JS questions?
[18:33] <deryck> bac, sure.  I forgot about your jssize question.  sorry
[18:33] <bac> np
[18:34] <bac> deryck: do you have time now?
[18:34] <deryck> sure.  let me grab headphones
[18:35] <lifeless> benji: ok, lets talk constraints
[18:36] <lifeless> benji: all I care about is that the page list the known scopes etc; if we want the page to be 'sufficient to write a rule' then I care that the exposition about the rules, and the whys, and the approval policy be 'present or linked'.
[18:37] <lifeless> I dunno if that parses
[18:37] <lifeless> benji: and with that let me get out of your hair and let you do it as you think best ;)
[18:39] <benji> lifeless: I parsed it -- correctly, I think. :)  My understanding of the original bug (636193) was to "list the known", which seems like a subset of "sufficient to write a rule" which could be a new bug, so I'll claim victory with the current state of the branch plus feedback from Chex when he gets a chance to look at the screenshot.  Thanks for the input.
[18:40] <lifeless> my pleasure, sorry to drag this offbase.
[18:40] <lifeless> Bad habit of mine
[18:40] <benji> lifeless: on a related note, you reviewed the branch and found one flaw that I've since fixed, do you feel comfortable marking the code part accepted now? (https://code.launchpad.net/~benji/launchpad/bug-636193/+merge/46350)
[18:41] <lifeless> benji: I think the test_unknown_scope
[18:41] <lifeless> should do self.assertFalse(scopes.lookup('not-a-real-scope'))
[18:42]  * benji looks
[18:42] <lifeless> otherwise a legitimate implementation could return 'yipee-a-i-m*f*' for unknown scopes,
[18:42] <benji> heh
[18:42] <benji> ok, will do
[18:43] <lifeless> benji: can I suggest showing the info on the +feature-rules page, rather than a separate page?
[18:43] <lifeless> benji: seems like less clicking for admins, and the rules for visibility are identical
[18:43] <lifeless> but perhaps thats tricky to do? If so its not a big deal
[18:44] <benji> lifeless: that'd be fine with me; I was expecting that they'd open them in multiple tabs/windows (being expert users) and that they would prefer that to scrolling up and down
[18:44] <benji> I think it'd be easy to do.
[18:45] <lifeless> benji: lets see what $losa says
[18:45] <lifeless> mbarnett: yo, I know you're around :P
[18:45] <benji> sounds good
[18:46] <lifeless> docstring_dedent seems like it really wants to live somewhere more common
[18:48] <lifeless> benji: getUserBrowserAsTeamMember looks like its copied from somewhere? perhaps pull up to the base class?
[18:48] <lifeless> at a guess getUserBrowserAsAdmin too
[18:49] <lifeless> benji: recommendation: rather than using tearDown, use addCleanup in setUp
[18:50] <benji> lifeless: putting it in a more general place would be reasonable.  I normally follow the rule to promote something to a wider scope when it's needed in that scope, but that does assume the knowlege that the thing exists, so the alternative of "put general things in a general place" might pervail in a project with so many devs as LP.
[18:50] <lifeless> benji: or even make a small Fixture to save and restore those things - I see lots of semi-repetitive code
[18:50] <benji> lifeless: re. addCleanup indeed; I'll do that
[18:50] <benji> I'll look into making a Fixture.
[18:51] <lifeless> (bin/pydoc fixtures is a good starting point for that)
[18:52] <mbarnett> lifeless: looking into another problem, will need a moment.
[18:52] <lifeless> mbarnett: no panic
[18:52] <lifeless> benji:
[18:52] <lifeless> 440	+    def __init__(self, request):
[18:52] <lifeless> 441	+        self.request = request
[18:53] <lifeless> is repeated in most (all?) scopes; perhaps move to the base?
[18:53] <benji> +1
[18:53] <lifeless> in fact, its on the base, just needs gc :)
[18:53] <benji> :)
[18:55] <lifeless> ok thats all; the structure looks fine. I can see a few places where I might have done it different, but none that matter in any significant way
[18:55] <lifeless> I'm going to mention one of them
[18:55] <lifeless> which is that I probably would have delegated the 'can handle' check rather than exposing a predicate regex
[18:56] <lifeless> anyhow, I'll change my vote now because the critical stuff is already done
[19:04] <benji> lifeless: thanks.  A small note on the exposed regex (sounds like something you'd go see a doctor for), I did it that way because I wanted to use the regex in the info page (which seemed sane only because it is developers and losas who will be reading it).  Perhaps that should have just been non-executable words decribing the structure of the scopes along with code for "can handle" as you suggest.  But, as you say, it's done and the 
[19:05] <lifeless> your text cut off
[19:05] <lifeless> at
[19:05] <lifeless> 'done and the'
[19:08] <benji> "it's done and the way it is now won't kill any kittens."
[19:08] <lifeless> right
[19:08]  * benji applies -q to himself.
[19:09] <flacoste> lifeless, benji: updating a LEP once something is implemented is a waste of time in my IMHO
[19:09] <flacoste> design documents are historical
[19:09] <flacoste> not live documentation
[19:09] <flacoste> the code is the ultimate source
[19:15] <benji> flacoste: I agree.  The maintenance overhead is pretty high and, historically speaking, unlikely to keep pace with the code.  I wish I knew how to really do architechural documentation, but I don't.
[19:29] <sinzui>  deryck, regarding the ajax retarget project bug. does the callback update the new project's milestones and check permission that I can change status and importance?
[19:30] <lifeless> flacoste: LEPs are not implementaiton docs
[19:31] <deryck> sinzui, I'm sure it checkes perms.  Not sure about updating milestones.
[19:31] <lifeless> flacoste: they document constraints and goals
[19:31] <lifeless> flacoste: keeping those up to date is valuable IMO
[19:31] <flacoste> lifeless: they also serve as design documents
[19:31] <flacoste> as more artefacts are added to it
[19:31] <flacoste> like mock-ups
[19:31] <flacoste> and other stuff
[19:32] <lifeless> flacoste: so, we could delete all that stuff easily when the thing is done, and be left with the core
[19:32] <flacoste> i agree that keeping constratins and goals up to date is valuable
[19:35] <thumper> leonardr: morning
[19:35] <leonardr> thumper, hi
[19:35] <leonardr> https://code.launchpad.net/~leonardr/launchpad/fix-xhtml-encoding/+merge/47551
[19:35] <leonardr> that's in ec2 now
[19:35] <thumper> leonardr: exactly the question I was going to ask :)
[19:44] <lifeless> flacoste: so it sounds like delete-the-redundant-stuff-after-impl and keep live, will make us both happy?
[19:45] <flacoste> lifeless: it would, i'd be interested in what jml thinks, care to ask the list and him for feedback, we could make that the last step of the approval process?
[19:45] <lifeless> sure thing
[19:49] <thumper> leonardr: any idea why I can't run all the lazr.restful tests?
[19:50] <leonardr> thumper: i think i only said this in email, but your patch doesn't solve the problem for the default field renderer
[19:50] <leonardr> so it might be causing failures there. can you paste me the failures?
[19:50] <thumper> leonardr: I get exactly the same errors running on trunk
[19:51] <thumper> leonardr: http://pastebin.ubuntu.com/558680/
[19:51] <bigjools> lifeless: check this out and tell me what you think https://code.launchpad.net/~julian-edwards/launchpad/debversion-denormalise/+merge/47578
[19:52] <leonardr> thumper: yeah, that's something different. let me just try a sanity check
[19:52] <thumper> leonardr: ok
[19:53] <lifeless> bigjools: did you intend to drop the bz2 stuff?
[19:55] <bigjools> lifeless: que?
[19:55] <lifeless> bigjools: read the diff
[19:55] <lifeless> +COMMENT ON COLUMN NameBlacklist.admin IS 'The person who can override the blacklisted name.';
[19:55] <lifeless> etc
[19:55] <bigjools> lifeless: the diff is crack
[19:55] <lifeless> MULTIPROC=0j 4
[19:55] <bigjools> completel crack, wtf
[19:55] <bigjools> oh shit
[19:56] <bigjools> wrong merge target
[19:57] <lifeless> bigjools: ok, so a few thoughts
[19:57] <leonardr> thumper: the trunk tests pass for me, so it may be a problem with your setup
[19:57] <lifeless> bigjools: I'd consider leaving the old index in place
[19:57] <bigjools> lifeless: wait up :)
[19:57] <thumper> leonardr: probably...
[19:57] <leonardr> did you by any chance help jcsackett with his problem yesterday? he had a problem pertaining to error views
[19:57] <lifeless> bigjools: and making the new one live after the deploy
[19:57] <thumper> leonardr: points to some missing dependencies or something
[19:58] <thumper> leonardr: no, I didn't talk to jcsackett yesterday
[19:58] <lifeless> bigjools: that would reduce the time to do the db patch
[19:58] <bigjools> lifeless: why's that? - I can probably guess why but...
[19:58] <leonardr> let me think more deeply about the errors
[19:58] <jcsackett> leonardr: you solved the only issue i was having yesterday.
[19:58] <leonardr> either FakeRequest is not being considered a request, or the default registration for IClientErrorView is not taking effect
[19:59] <bigjools> lifeless: on dogfood it was pretty quick - about 5 mins.  Production will be significantly quicker
[19:59] <bigjools> lifeless: new one https://code.launchpad.net/~julian-edwards/launchpad/debversion-denormalise/+merge/47580
[19:59] <lifeless> bigjools: 5 minutes is -slow- :)
[20:00] <bigjools> lifeless: dogfod is S L O W
[20:00] <bigjools> prod is typically an order of magnitiude quicker
[20:00] <lifeless> its going to be running python
[20:00] <abentley> thumper, I can has review? https://code.launchpad.net/~abentley/launchpad/build-mail2/+merge/47563
[20:01] <bigjools> lifeless: que?
[20:02] <lifeless> bigjools: debversion_sort_key is plpython isn't it ?
[20:02] <bigjools> lifeless: no
[20:02] <bigjools> ummm maybe
[20:03] <lifeless> by which you mean yes?
[20:03] <wgrant> Have we considered using postgresql-8.4-debversion?
[20:03] <lifeless> there are 5million rows in the table
[20:03] <bigjools> how do I find out
[20:04] <bigjools> lifeless: like I said, it will not be that slow on production hardware
[20:04] <leonardr> thumper: not sure what this means, but i can get your first three errors by removing the final stanza from src/lazr/restful/configure.zcml
[20:04] <bigjools> lets consider only changing it if we go over budget
[20:04] <thumper> ?!?
[20:05] <leonardr> thumper: can you check your zope eggs for local changes?
[20:05] <lifeless> wgrant: I don't think we have, no.
[20:05] <wgrant> bigjools, lifeless: There is an index on debversion_sort_key(version) already... I don't see the point of denormalising.
[20:05] <thumper> leonardr: I was running from a fresh branch of lp:lazr.restful
[20:05] <thumper> leonardr: so it isn't in an egg
[20:05] <thumper> leonardr: it did that real slow buildout process
[20:05] <bigjools> wgrant: it's not about the index
[20:06] <bigjools> it's about the speed of calling that function
[20:06] <lifeless> bigjools: LANGUAGE plpythonu IMMUTABLE RETURNS NULL ON NULL INPUT AS
[20:06] <bigjools> which is shitty slow
[20:06] <leonardr> thumper: incidentally, i remembered how to stop the slow buildout process
[20:06] <wgrant> To do what?
[20:06] <lifeless> bigjools: its plpython
[20:06] <wgrant> It is mostly used for sorting.
[20:06] <bigjools> lifeless: ok
[20:06] <thumper> leonardr: I'd love to know
[20:06] <wgrant> Sorting should be handled by the index.
[20:06] <lifeless> bigjools: doing an re.compile on *every call*
[20:06] <lifeless> arggggggggggggggggggggggggggg
[20:06] <leonardr> thumper: you need a ~/.buildout/default.cfg
[20:06] <leonardr> mine looks like this
[20:06] <bigjools> lifeless: nice!
[20:06] <leonardr> [buildout]
[20:06] <leonardr> eggs-directory=/home/leonardr/.buildout/eggs
[20:06] <leonardr> download-cache=/home/leonardr/.buildout/download-cache
[20:06] <leonardr> except without all that whitespace
[20:06] <lifeless> bigjools: hand me a spork, I must remove mine eyes
[20:07] <bigjools> wgrant: it doesn't use it when the sort is across columns on different tables
[20:07] <lifeless> bigjools: for your pleasure: database/schema/trusted.sql
[20:07] <leonardr> create those directories and the eggs will be cached
[20:07] <lifeless> wgrant: see my perf tuesday mail from wednesday
[20:08] <bigjools> lifeless: huh.... had no idea it was in there!
[20:08] <lifeless> bigjools: anyhoe, 5M rows, 0.5ms per row, 2500seconds
[20:08] <bigjools> wgrant: I made the column on DF and it reduced a query from 350ms to 200 by using it instead of the  func
[20:08] <lifeless> bigjools: thats for binarypackagerelease only
[20:08] <thumper> leonardr: ah... cool
[20:09] <bigjools> lifeless: where did you get that stat from?
[20:09] <wgrant> Ah, I see.
[20:10] <lifeless> bigjools: the time it takes to add the column into the intermediary table in the OOPS we see
[20:10] <lifeless> bigjools: 55K rows takes 10 seconds
[20:10] <bigjools> now, if we had name as a string on the SPR/BPR tables ...
[20:10] <bigjools> hmmm that sounds dodgy
[20:10] <lifeless> bigjools: right, we could index name, version, id desc
[20:11] <bigjools> lifeless: I'm kinda tempted to do that but it's a major change
[20:11] <lifeless> bigjools: indeed; I want to talk to stub about a cross table function
[20:11] <lifeless> bigjools: resulting in a per-table index
[20:11] <lifeless> I dunno if its possible
[20:11] <bigjools> I'm interested
[20:11] <lifeless> hes on leave for a bit
[20:12] <bigjools> jtv is back tomorrow, he'd know
[20:12] <lifeless> basically I'm wondering if we can put an index on the history table or the packageversion table
[20:12] <lifeless> index foo on FUNCTION()
[20:12] <lifeless> erm
[20:12] <lifeless> FUNCTION(id)
[20:13] <lifeless> and have the function grab stuff from related tables and return a tuple
[20:13] <bigjools> you can do that, see binarypackagerelease_version_sort
[20:13] <wgrant> That would be really useful, but I've never seen it done before.
[20:13] <bigjools> although not sure how you'd access related tables, there must be a way
[20:14] <leonardr> thumper: here's my advice for getting to the bottom of this. put a breakpoint in AbsoluteURL.__str__ or getMultiAdapter, so that you get a breakpoint when there's an exception
[20:14] <leonardr> and then look at the registered adapters
[20:14] <lifeless> bigjools: right, I know you can build on a function
[20:14] <lifeless> bigjools: the question is if you can build on a function *that accesses other tables*
[20:14] <bigjools> lifeless: anyway are you ok with the general direction of that patch?
[20:14] <thumper> leonardr: ok, I'll look at it later. Got other things that have bubbled to the top of the todo list
[20:14] <wgrant> sinzui: How is the translations export issue?
[20:15] <lifeless> anyhow, if you can you'd return (name, debversion_sort_key)
[20:15] <leonardr> thumper: you can call getGlobalSiteManager().registered_adapters() to get an iterator over the registered adapters
[20:15] <lifeless> bigjools: 700K souce package releases
[20:15] <leonardr> see why the appropriate adapter isn't registered
[20:15] <lifeless> so 6M total calls we need to make
[20:15] <leonardr> but, i'm pretty sure it's a problem with your setup (although it could easily be a problem with my setup, since i'm the main person who runs the lazr.restful tests. but, i changed computers recently)
[20:15] <sinzui> wgrant: I have not looked beyond the bug since I have been chasing mailman issues
[20:15] <bigjools> creating the index is fast after the column is added, on DF it was seconds
[20:16] <sinzui> wgrant: I did intend to work on it today
[20:16] <wgrant> sinzui: I'll do it shortly.
[20:16] <lifeless> bigjools: sure am, the extra column is totally fine given our state of the art
[20:16] <lifeless> bigjools: let me do a quick test
[20:16] <jcsackett> sinzui, wgrant: i had machine issues, so i have not looked at it either.
[20:16]  * bigjools waits
[20:17] <wgrant> sinzui: Ooh, squad assignment. I like it.
[20:17] <lifeless> bigjools: the only concern I have is whether to do it all at once or just add the facility, populate & use in a couple of steps
[20:17] <sinzui> bigjools: wgrant, lifeless, I reported a bug about 18 months ago that the db's debversion is not the same as launchpads. Many pages use Lp because is behaves better. I think we should have one trusted way to sort by version
[20:18] <bigjools> we should look at installing the PG package
[20:18] <wgrant> We should. It is C, so should be faster.
[20:18] <bigjools> exactly
[20:18] <bigjools> re.compile on every invocation..... aieeee
[20:18] <wgrant> Yeah, taking that into account, it should be a LOT faster.
[20:18] <bigjools> and, it's a package, so it, errr, gets bugfixes
[20:18] <lifeless> sinzui: we'll need two versions
[20:18] <sinzui> bigjools: blackname list is compiles once ons startup, why isn't debversion
[20:19] <lifeless> sinzui: but they should be identical, and the current function isn't up to scratch
[20:19] <bigjools> sinzui: see database/schema/trusted.sql
[20:19] <lifeless> bigjools: select debversion_sort_key(version) from sourcepackagerelease;
[20:20] <lifeless> Time: 71177.609 ms
[20:20] <lifeless> bigjools: so ~ 5 minutes for all
[20:20] <bigjools> lifeless: so let's install this package and deprecate our plpython
[20:20] <wgrant> Hmm. How quickly can we get that installed on mawson to test? :)
[20:20] <lifeless> bigjools: its a new datatype
[20:20] <bigjools> lifeless: on which system?
[20:20] <lifeless> bigjools: we need to significantly more than just install it; I agree its a great thing to do though.
[20:20] <lifeless> bigjools: sourcherry
[20:20] <bigjools> new datatype?
[20:20] <sinzui> bigjools: okay. blackname list does multiple compiles to cover the two paths we might take through the method (admin vs approved tesm)
[20:21] <sinzui> maybe I can help make a faster version
[20:21] <lifeless> bigjools: the postgreslq-8.4-debversion package adds a custom datatype to postgresql
[20:21] <bigjools> that which the function returns?
[20:21] <wgrant> So you don't use a function; you can just use normal operators on the column.
[20:21] <lifeless> This package
[20:21] <lifeless>  implements a "debversion" type to represent Debian version numbers
[20:21] <lifeless>  within the PostgreSQL database.
[20:21] <bigjools> yeah, we don't give a rats ass about the type really
[20:21] <thumper> abentley: this is just a refactoring branch?
[20:21] <lifeless> we'll need to do data & code migration
[20:22] <lifeless> bigjools: well, we might if it works well
[20:22] <abentley> thumper, correct.  I'm building the mail changes on top of it now.
[20:22] <bigjools> lifeless: no we won't - we can just use it to populate a new column that we sort on
[20:22] <thumper> abentley: ok
[20:22] <lifeless> bigjools: thats data migratoin and code migration :)
[20:22] <bigjools> lifeless: it's trivial
[20:22] <lifeless> sure
[20:22] <lifeless> just needs to be done
[20:22] <bigjools> I'll do it then
[20:23] <lifeless> in a bunch of places, and we need to make sure we don't regress anything
[20:23] <lifeless> I'm pro doing it
[20:23] <bigjools> not in a bunch of places actually :)
[20:23] <lifeless> just refusing to underestimate ;)
[20:23] <bigjools> just where it's inserted
[20:23] <bigjools> we never read it directly
[20:24] <lifeless> we never read BinarhyPackageRelease.version ?
[20:24] <bigjools> that's a separate column
[20:25] <bigjools> I am talking about adding a new column that we initially only sort on
[20:25] <bigjools> then we can take our time migrating from the old version to the new one
[20:25] <lifeless> I imagined that the point of the custom data type is to have that *as* the version column, eventually.
[20:25] <bigjools> yes, eventually
[20:25] <lifeless> bigjools: right, and thats the cost I'm referring to :)
[20:25] <bigjools> pffff
[20:25] <lifeless> anyhow, FWIW, +1 from me.
[20:25] <bigjools> it's still trivial :)
[20:26] <lifeless> I'm very interested to hear how it behaves on mawson
[20:26] <bigjools> lifeless: so, the first thing to ask is that does that package give a debversion_sort_key in C instead of plpython
[20:26]  * bigjools looks
[20:26] <lifeless> bigjools: AIUI no
[20:26] <lifeless> bigjools: it gives a new datatype; you might be able to cast into that datatype from TEXT
[20:27] <bigjools> ah ok, makes sense
[20:28] <lifeless> it has direct glue such that an index ON column-of-that-datatype results in something sane
[20:28] <bigjools> right - so it's roughly equivalent of my patch, except it's not text, it's the new type
[20:29] <lifeless> so you could do on $casted-text to replicate the brittle situation we have today
[20:29] <lifeless> bigjools: yes
[20:29] <bigjools> ok this makes me happy - I'll go with this patch for now and then it's super easy to change later
[20:29] <lifeless> yeah
[20:30] <bigjools> my eyes are still bleeding from that plpython....
[20:30] <lifeless> I suspect the re.compile is ~most of the time.
[20:31] <wgrant> I wonder if it's changed since 2004.
[20:31] <lifeless> blame
[20:34] <wgrant> Ah, it was only written in 2006.
[20:35] <bigjools> wgrant: sanity check: SPRs are created in gina and distroseries.createUploadedSourcePackageRelease only, right?
[20:36] <wgrant> bigjools: I hope so.
[20:36] <wgrant> But maybe you should use triggers?
[20:36] <bigjools> wash your mouth out young man
[20:37] <wgrant> The test suite and factory and blah blah blah will all create them.
[20:37] <bigjools> ah factory was one more place
[20:37] <wgrant> A trigger is easy.
[20:37] <wgrant> And makes more sense.
[20:37] <bigjools> it's also shit ugly and hard to change
[20:37] <lifeless> wgrant: triggers are problematic
[20:37] <wgrant> So is this whole idea :)
[20:38] <wgrant> lifeless: Sure. But even in this case?
[20:38] <bigjools> triggers are a bit like regexes
[20:38] <bigjools> if you use them to solve a problem, you now have 2 problems
[20:38] <lifeless> heh
[20:38] <lifeless> theres a time and a place
[20:39] <lifeless> I don't particularly care either way here, because we're unlikely to read-back the field *in this iteration*
[20:39] <wgrant> leonardr: Is your EntryFieldResource fix in ec2?
[20:39] <bigjools> well, yes we are by the time I'm done :)
[20:39] <wgrant> Oh.
[20:39] <wgrant> It's in PQM, even
[20:39] <lifeless> bigjools: right, later iterations will be a problem
[20:40] <bigjools> yes
[20:40] <bigjools> and I don't want to be left in a situation where we find a crappy bug and can't fix it until the next downtime
[20:41] <lifeless> indeed
[20:58] <huwshimi> Morning.
[20:59] <rambo> huwshimi: morning to you too
[21:08] <StevenK> sinzui: Hi -- I'm fixing person/team merges to delete recipes, but I can't see any tests for this sort of thing -- I am missing something?
[21:10] <sinzui> StevenK: yes, one moment
[21:14] <sinzui> StevenK: /lib/lp/registry/tests/test_person.py TestPersonSetMerge is where you want to add your test
[21:15] <StevenK> I did, it broke :-)
[21:15] <sinzui> StevenK: the historical test is a a doctest called doc/person-merge.txt, but I weep when I read it
[21:16] <StevenK> Haha
[21:16] <sinzui> StevenK: was the break because there were references left in the db?
[21:16] <wgrant> StevenK: Merges deleting recipes? Shouldn't only delete-merges delete recipes?
 did wontfix go away?
[21:17] <poolie>  or is there an acl on setting it?
[21:17] <poolie> it seems odd i can mark 676766 invalid but not wontfix
[21:17] <leonardr> i need some advice from someone who knows about soyuz
[21:18] <poolie> hello leonardr!
[21:18] <bigjools> o/
[21:18] <james_w> poolie, there's an ACL IIRC
[21:18] <StevenK> leonardr: O hai
[21:18] <wgrant> poolie: Only the bug supervisor can set Won't Fix.
[21:18] <wgrant> Hi leonardr.
[21:18] <bigjools> hi leonardr :)
[21:18] <poolie> ok
[21:18] <leonardr> i did not expect such an outpouring of support
[21:18] <bigjools> we are passionate people
[21:19] <poolie> much better than expecting enthusiasm and not getting it :-)
[21:19] <leonardr> general question: are there any objects in soyuz that are published on the web service but not on the website?
[21:19] <StevenK> Yes, packagesets
[21:19] <wgrant> ArchivePermissions
[21:19] <lifeless> any reason they are not published on the website?
[21:19] <wgrant> BPRDCs
[21:19] <lifeless> e.g. time ?
[21:19] <wgrant> They are published, but they have no views.
[21:19] <bigjools> because they need a complicated UI design
[21:19] <StevenK> wgrant: Currently, if the from_person has recipes, they are left untouched, and then can't be gotten at.
[21:19] <wgrant> Right, it's not obviously waht the UI is.
[21:20] <bigjools> and it wasn't needed at the time
[21:20] <wgrant> StevenK: Right. We should probably move them to the target person, unless it's a delete-merge, in which case we could delete them.
[21:20] <StevenK> Platform are perfectly happy fiddling with packagesets over the API, FWIW.
[21:20] <bigjools> yeah but a visual rep at some point would be nice
[21:22] <wgrant> Then there are things like BPPH and SPPH which have no browser index, but do have some fragment views.
[21:22] <leonardr> the reason i ask is that web service objects are about to get a 'web_link' attribute and i need to know when to suppress that link
[21:23] <wgrant> Hmm.
[21:23] <leonardr> so far i have "hwdb stuff", ICountry, IArchivePermission, and the various IPackageSet classes
[21:23] <wgrant> Is it worth suppressing them?
[21:23] <leonardr> i was getting a lot of test failures in soyuz and the urls generated didn't look like real launchpad website urls, so i thought i'd ask
[21:24] <leonardr> i don't think it's worth going on a witch hunt, but given that the existing tests are failing, i'd rather fix the failure by suppressing the link than fix it by changing the test to look for a useless link
[21:24] <bigjools> maybe we need a property on the object somewhere to say that it has no UI
[21:24] <wgrant> Are you generating good URLs for things like branches and MPs, that only exist on code.lp.net?
[21:24] <lifeless> we should fix that
[21:25] <wgrant> I mean, could you just check to see if there is a +*index view?
[21:25] <bigjools> or you can examine the zcml to see if a template is defined
[21:25] <abentley> thumper, changing around with which transactions get committed worries me.
[21:25] <lifeless> jml would like one domain for everything (except librarian)
[21:25] <wgrant> lifeless: +1
[21:25] <leonardr> since this is not launchpad code, i can't really make that kind of deep introspection
[21:25] <bigjools> urgh
[21:25] <bigjools> blacklisting is kinda nasty
[21:25] <wgrant> I'd just create a web_url for everything.
[21:25] <leonardr> wgrant: code.lp.net works there are a couple problematic cases, where the vhost should be lp.net but it's actually api.lp.net. i intend to look at those separately
[21:26] <wgrant> If people access it and it 404s, that's their problem.
[21:26] <lifeless> leonardr: OTOH this code was written to support LP; can you think of anyway (relayering perhaps?) to make this work better
[21:26] <lifeless> or as wgrant says, just include it
[21:26] <leonardr> i don't think it's someone else's problem if we publish a link that doesn't work
[21:26] <lifeless> and note in the docs that this is a probable url, things not published won't be usable, things on whacky domains may not be usable
[21:27] <bigjools> I agree
[21:27] <lifeless> I'd hate the overhead of this to dominate api requests :)
[21:27] <thumper> abentley: feel free to land what you have and it can be refactored later
[21:28] <leonardr> as i understand it, determining whether there's a web view for a given url requires traversing the url. is that right?
[21:28] <bigjools> wgrant: have we got anything that generates the same crap as debian_sort_key anywhere in the code?
[21:28] <bigjools> debversion_sort_key even
[21:28] <wgrant> bigjools: I hope not.
[21:28] <lifeless> bigjools: god no
[21:28] <wgrant> leonardr: Can't you just look up the adapter for the object?
[21:28] <bigjools> I didn't think so
[21:29] <wgrant> leonardr: Since you presumably have the object.
[21:29] <bigjools> so how TF do I populate it :/
[21:29] <leonardr> wgrant: adapt it to what? i do have the object
[21:29] <lifeless> bigjools: there are no tests for it
[21:29] <wgrant> bigjools: Triggers.
[21:29] <StevenK> lifeless: So, why do you think my MP will involve recipes only being built every 2 days?
[21:29] <wgrant> leonardr: Views are adapters.
[21:29] <bigjools> wgrant: blah blah  blah! :)
[21:29] <wgrant> leonardr: You need a browser request, an object, and a view name.
[21:30] <lifeless> StevenK: its a boundary problem
[21:30]  * bigjools weeps
[21:30] <lifeless> StevenK: 24 hour check frequency + lag to build + 24 hour window
[21:30] <StevenK> It's date_created!!
[21:30] <StevenK> When the build is *CREATED*, not when it started or finished
[21:30] <lifeless> StevenK: ok, so it will still need a little slack
[21:31] <lifeless> e.g. 10 minutes
[21:31] <StevenK> lifeless: Okay, so I change it to 23 hours and 50 minutes
[21:31] <lifeless> StevenK: I think that would address that concern. The one that really worries me is the doing to much work thing.
[21:31] <lifeless> StevenK: why does it even examine recipes that are too fresh ?
[21:32] <StevenK> Because it was designed to run once a day
[21:32] <StevenK> I'll look at changing the call to see if the db can do the lifting for us.
[21:32] <lifeless> StevenK: I have a suggestion; you may like (or hate). Move it into the garbo as a tunableloop.
[21:32] <lifeless> that runs every hour
[21:32] <lifeless> and will deal with overload gracefully etc
[21:32] <StevenK> I'd prefer it ran more often
[21:33] <lifeless> we can do that too, quite easily if we want to. Why ?
[21:33] <leonardr> wgrant: i can create a new marker interface IWebsiteView. i can register a general adapter to WebsiteView such that getMultiAdapter((object, request)), IWebsiteView) is the same as getMultiAdapter((object, request), name='+index')
[21:33] <leonardr> is that the kind of thing you're thinking of?
[21:33] <leonardr> the interface would be defined in lazr.restful and the adapter would be defined in launchpad
[21:33] <wgrant> leonardr: Sort of. Except that rootsites screw everything up.
[21:34] <leonardr> wgrant: how so? the adaptation for a code.lp.net object won't succeed if the request is a lp.net request?
[21:37] <wgrant> leonardr: There will be no +index; just a +code-index.
[21:37] <wgrant> I believe.
[21:38] <bigjools> lifeless: did you see my suggestion about soyuz on staging?
[21:38] <lifeless> bigjools: yes thanks; its in my todo queue
[21:38] <wgrant> bigjools: FWIW, that email looked OK to me.
[21:38] <bigjools> lifeless: ok, I'll wait around before filing RTs
[21:38] <wgrant> But I think we will have to regularly move the archives away.
[21:38] <bigjools> yes
[21:38] <wgrant> Since running the publisher on a forked archive is going to BOOM.
[21:39] <bigjools> yes
[21:39] <leonardr> wgrant: is there any way to determine by looking at an object whether the named adapter is +index, +code-index, or what?
[21:39] <lifeless> jam: did I answer your question in the perf thread?
[21:41] <wgrant> leonardr: I believe it's specified through the defaultView directive. But I don't know its mechanics.
[21:41] <wgrant> Also, layers.
[21:41] <wgrant> IBranch has +index, but it's on CodeLayer.
[21:41] <jam> lifeless: I think part of it was "this is interesting,but I'm not sure I understand what you're saying", so I tried to piece it out and compose a mail as I went
[21:42] <StevenK> Bwaqhaha
[21:42] <jam> but yes, I think you've covered my interest
[21:42] <StevenK> s/q//
[21:42] <wgrant> leonardr: So, good luck with that!
[21:42] <StevenK> wgrant: The merge code has an XXX from cprov that states "We only allow one PPA per user"
[21:42] <lifeless> jam: making sql fast is tricky ;)
[21:42] <wgrant> StevenK: Yeah...
[21:43] <StevenK> wgrant: I can't see anything in the merge code for 'delete-merge'
[21:44] <wgrant> StevenK: I don't know where the codepaths diverge.
[21:44] <wgrant> But one is taken when you press 'Delete team'.
[21:44] <wgrant> It deletes stuff, and merges into ~registry.
[21:45] <StevenK> Perhaps sinzui knows
[21:46] <bigjools> postgresql-8.4-debversion seems to be uninstallable
[21:46] <wgrant> bigjools: Oh?
[21:46] <wgrant> Works here.
[21:46] <bigjools>  postgresql-8.4-debversion : Depends: libapt-pkg-libc6.10-6-4.8
[21:46] <wgrant> This is a boring old maverick i386 machine, though.
[21:47] <bigjools> I am amd64 maverick
[21:47] <lifeless> what does rmadison claim vis-a-vis lucid
[21:47] <bigjools> "libapt-pkg-libc6.10-6-4.8" exists in the package database, but it is not a
[21:47] <bigjools> real package and no package provides it.
[21:47] <bigjools> grrr
[21:48] <sinzui> StevenK: delete team == merge team into ~registry. it is just a special case where we know the target and we do some extra cleanup before we start the merge
[21:49] <sinzui> StevenK: that happen in a view. I reported a bug that the merge rules are wrong for delete because ~registry should not be given subscriptions or  assignments,
[21:51] <bigjools> wgrant: when did you install it?
[21:51] <wgrant> bigjools: About 5 minutes ago.
[21:51] <leonardr> wgrant: i'm interpreting what you're saying as that 'finding the ones we're not using and suppressing their links' is not such a bad idea in practice
[21:51] <bigjools> wgrant: wtf is solving that dependency for you?
[21:51] <wgrant> leonardr: Not such a bad idea in theory, but difficult in practise.
[21:52] <wgrant> And probably not terribly useful.
[21:52] <jcsackett> sinzui: i have had a total computer crash. may not be up and running again come 5:30.
[21:52] <wgrant> It would be *nice*, but it's hard.
[21:52] <wgrant> bigjools: Checking...
[21:52] <bigjools> some weird crap going on here
[21:52] <leonardr> wgrant: we may be talking about different solutions. i'm not talking about the adapter-based solution
[21:53] <sinzui> jcsackett: understood
[21:53] <wgrant> bigjools: Yes.
[21:53] <leonardr> i'm talking about the one where we add publish_web_link=False to selected export_as_webservice_entry() calls
[21:53] <leonardr> that already works, and if we overlook a couple it's not a disaster and it's easy to fix
[21:53] <wgrant> Ahh.
[21:53] <bigjools> wgrant: libapt-pkg-libc6.10-6-4.8 is needed by the superseded version....
[21:53] <wgrant> leonardr: That sounds good.
[21:53] <wgrant> leonardr: As long as missing one doesn't break anything.
[21:54] <leonardr> the worst that will happen is someone will follow that link, get a 404, and we'll fix it
[21:54] <wgrant> bigjools: postgresql-8.4-debversion here wants libapt-pkg4.10, which apt provides.
[21:54]  * bigjools scratches head
[21:54] <wgrant> bigjools: My natty amd64 box also wants libapt-pkg4.10.
[21:54] <bigjools> yes that's what LP is telling me
[21:55] <bigjools> it wants to install 1.0.3-1 instead of 1.0.3-1build1
[21:55] <wgrant> sinzui: You're running Newnity, right?
[21:56] <sinzui> I am
[21:56] <sinzui> It is stable today
[21:56] <wgrant> sinzui: I upgraded my desktop to xorg-edgers and dropped fglrx yesterday, and it now runs OK.
[21:56] <wgrant> But the thing that appears when I click on the Ubuntu button in the top right is a bit odd.
[21:57] <wgrant> It takes up like 1/4 of the screen and doesn't do much.
[21:57] <wgrant> And is all corrupt.
[21:57] <wgrant> Is yours any better?
[21:58] <bigjools> wgrant: WTF - something's corrupted my sources.list to use lucid....!
[21:58] <sinzui> wgrant: oh good. I gave up and removed that ppa. I will try it again on my other computer. The menu is busted
[21:59] <sinzui> wgrant: desktop is missing zietgiest goodness I think. That was the origin of my broken desktop 12 days ago
[21:59] <wgrant> bigjools: Ahaha.
[21:59] <bigjools> "Need to get 166MB of archives."
[21:59] <bigjools> sigh
[22:00] <wgrant> sinzui: I'm on a newish Radeon, so the new Gallium3D drivers are all that work. I presume older and more Intel cards don't need xorg-edgers at all.
[22:00] <lifeless> well
[22:00] <lifeless> on natty xorg-edgers is landing in main atm
[22:00] <lifeless> aka boom
[22:01] <wgrant> It is, yeah.
[22:01] <wgrant> I am pretty impressed with r600g, though.
[22:02] <wgrant> bigjools: How much of your sources.list was Lucidified? All of it?
[22:02] <bigjools> yes
[22:02] <wgrant> Huh.
[22:02] <bigjools> quite
[22:02] <bigjools> I have NFI what did that to me
[22:02] <sinzui> wgrant: I do have an older radeon. I was using edgers last year, but gave it up with maverick. Unity dependencies are easier to achieve with compiz. But as I wrote, desktop is missing bits that work on a netbook config
[22:03] <lifeless> sinzui: did you run the ppa removal tool ?
[22:03] <lifeless> sinzui: there was/is stuff in edgers that never hit the primary archive and has a higher version number
[22:03] <lifeless> if you don't run the removal tool, Things Will Break
[22:04] <sinzui> lifeless: no, I may have used the desktop's source panel.
[22:04] <lifeless> ppa-purge
[22:05] <sinzui> lifeless: I will keep that in mind
[22:18] <wgrant> Is qastaging broken?
[22:19] <wgrant> Most things seem to time out.
[22:19] <wgrant> And the DB never seems to reset.
[22:23] <StevenK> I noticed lots of timeouts while QAing in the airport lounge at Dallas.
[22:24] <lifeless> usually cold cache effects
[22:24] <wgrant> I finally got a page to load after about 20 retries.
[22:24] <wgrant> And the DB is still three months old :/
[22:25] <StevenK> I'm concerned about that -- I didn't think it would be *that* old
[22:26] <wgrant> It's from just before Natty was initialised.
[22:26] <henninge> wgrant: which one? staging or qastaging?
[22:26] <wgrant> henninge: qastaging
[22:27] <wgrant> staging seems to be OK.
[22:27] <sinzui> qastaging is ancient and awkward
[22:27] <henninge> yes, staging was restored on the 23rd
[22:27] <sinzui> I have been using staging for testing that needscurrent data
[22:33] <sinzui> wgrant: mumble?
[22:33] <wgrant> sinzui: Sure.
[22:34] <wgrant> Argh, Unity is breaking things.
[22:35] <wgrant> I can here you.
[22:35] <wgrant> *hear, argh.
[22:36] <StevenK> lifeless: So, isn't qastaging's database supposed to be done at the same time as staging's?
[22:36] <james_w> lifeless, would you explain what you mean by "conflicting UI requirements"?
[22:37] <james_w> there's no discussion in the bug or references to any
[22:43] <cjohnston> Whats up with the horribly long wait time for downloading translations?
[22:44] <cjohnston> Sorry.. Should have asked in #launchpad
[22:45] <wgrant> cjohnston: I'm fixing that right now.
[22:45] <wgrant> cjohnston: The exporter is broken at the moment.
[22:45] <cjohnston> Gotcha
[22:45] <cjohnston> thanks wgrant.
[22:45] <cjohnston> Will it take 3 days to catch up?
[22:45] <wgrant> I don't know enough to say, sorry.
[22:46] <cjohnston> Not a problem
[22:50] <wgrant> Hmm. I want a decorator that wraps a context manager.
[22:58] <bigjools> lifeless (or anyone), to use the debversion type we need to run a .sql file that comes with the package to load it into the database.  Is there a "right" way of doing that or shall I mangle it in with trusted.sql?
[22:59] <wgrant> Hm, that's a bit sad.
[22:59] <bigjools> yes :/
[22:59] <wgrant> I'd hack it into the Makefile, I think.
[23:01] <bigjools> yeah that's what I meant
[23:01] <bigjools> it's in schema/upgrade.py as well
[23:01] <bigjools> I need a dba
[23:01] <wgrant> Gaaaaah.
[23:02] <wgrant> Can't do that.
[23:02] <wgrant> Try running it a second time :(
[23:02] <bigjools> ok so it'll need to be run manually
[23:03] <wgrant> postgres appears to not do CREATE OR REPLACE OPERATOR
[23:03] <bigjools> but the Makefile needs it for .dev
[23:05] <lifeless> flacoste: ping
[23:06] <lifeless> james_w: on the one hand claim is *meant* to stpo notifying other folk; on the other hand you want it to *keep* notifying other folk
[23:06] <lifeless> bigjools: put it in a patch script
[23:06] <lifeless> those are run once.
[23:06] <bigjools> lifeless: urgh
[23:09] <wgrant> Does anybody know if I can somehow curse a store such that attempts to access it will explode?
[23:10] <wgrant> In particular, I want to be able to test that the librarian client's addFile method doesn't touch the slave store, even in SlaveDatabasePolicy.
[23:10] <james_w> lifeless, I said an acceptable solution for me was to notify saying "this review has been claimed"
[23:10] <lifeless> james_w: I missed that
[23:10] <james_w> I just don't want a dead end in my email client, as I can't distinguish between "unclaimed" and "claimed" without a GET
[23:10] <lifeless> wgrant: monkey patch
[23:11] <wgrant> lifeless: I was hoping for something less bad.
[23:11] <wgrant> But OK.
[23:11] <wgrant> I guess I'll look around and see what the policy tests do.
[23:11] <thumper> hmm...
[23:11] <bigjools> Hermione Granger is less bad, and has the ability to curse stuff
[23:11] <thumper> leonardr: don't suppose you are still around?
[23:12] <wgrant> thumper: Is it still broken?
[23:13] <thumper> wgrant: no, this is something else
[23:13] <wgrant> Oh, good.
[23:13] <wgrant> As long as it's not a blocker.
[23:13] <thumper> https://bugs.launchpad.dev/api/devel/evolution/+bug/12/importance?ws.accept=text/json
[23:13] <_mup_> Bug #12: "Next 10 messages" changes Display Settings <lp-translations> <Launchpad itself:Fix Released by daf> < https://launchpad.net/bugs/12 >
[23:13] <thumper> I'd expect "Medium"
[23:14] <thumper> I get: [{"token": "UNKNOWN", "title": "Unknown"}, {"token": "CRITICAL", "title": "Critical"}, {"token": "HIGH", "title": "High"}, {"token": "MEDIUM", "selected": true, "title": "Medium"}, {"token": "LOW", "title": "Low"}, {"token": "WISHLIST", "title": "Wishlist"}, {"token": "UNDECIDED", "title": "Undecided"}]
[23:14] <thumper> https://bugs.launchpad.dev/api/devel/evolution/+bug/12?ws.accept=text/json
[23:14] <_mup_> Bug #12: "Next 10 messages" changes Display Settings <lp-translations> <Launchpad itself:Fix Released by daf> < https://launchpad.net/bugs/12 >
[23:14] <thumper> gives me a json dict
[23:14] <thumper> which has 'importance': 'Medium'
[23:14] <thumper> so I find the other request confusing
[23:15] <wgrant> thumper: It does at least have "selected": true.
[23:15] <wgrant> So it's not entiiiiirely useless.
[23:15] <thumper> not sure what to do about it though
[23:15] <thumper> wgrant: it does...
[23:15] <thumper> but my "refactoring" is broken because of this
[23:15]  * thumper will revert a small change
[23:15] <thumper> and refactor something else until I've chatted with leonardr about it
[23:15] <james_w> does it perhaps list them all so you know what the current user can select?
[23:16] <thumper> james_w: it does, I expect, but the behaviour is not consistent
[23:16] <thumper> that is the problem
[23:16] <james_w> ah, consistent with the full representation
[23:16] <thumper> james_w: I'd expect the json representation of the field to be consistent whether I ask for the entry or the field
[23:17] <thumper> I can guess why it was written that way
[23:17] <thumper> we may need to tweak :)
[23:17] <thumper> yay lazr.restful
[23:17]  * thumper goes to lunch
[23:18] <lifeless> sinzui: hi
[23:18] <lifeless> sinzui: branch deletion api
[23:18] <sinzui> yes
[23:18] <lifeless> sinzui: I've seen reference to some prior decision not to delete related assests
[23:18] <sinzui> yes. we make the user do it and the mode object raise an exception
[23:18] <lifeless> is there some where I can read up on that? It seems like we're just shuffling things around at the moment
[23:19] <sinzui> I do not think we ever document things like this in dev.lp.net
[23:19] <lifeless> sinzui: is there any reason we can't do that over the api ?
[23:19] <lifeless> sinzui: or just let the api delete succeeed ?
[23:19] <lifeless> sinzui: my concern is that this makes programmatic management of branches like the package import ones break down
[23:21] <sinzui> lifeless: I am current with the discussion I think the way to allow users to shoot themselves in the foot is to 1. add a method that does the extra work and 2. provide a delete_dependents=False arg to the delete method. Let the users be expclite
[23:21] <lifeless> sinzui: AIUI destructors may not accept arguments
[23:21] <lifeless> leonardr: ^ is this true ?
[23:22] <sinzui> lifeless:  less capable users are writing scripts that check for releases, milestones, packaging links, and delete them before deleting the master object
[23:23] <lifeless> sinzui: and merge proposals ?
[23:23] <sinzui> lifeless, this is also how some projects differ bugs to a new series/release
[23:23] <lifeless> sinzui: I believe you have you bypass ownership to do this
[23:23] <sinzui> That does not surprise me. that is what the other deletes do
[23:24] <sinzui> I can delete a series and your private bugtask goes, you have no control over it
[23:24] <lifeless> sinzui: which is why I'm saying that manually looking for and removing relations is not a good design or iddiom
[23:24] <sinzui> The owner of the master object wins, but that is why we let the users know the consequences in the UI
[23:25] <lifeless> sinzui: we don't do this on series though ... we just delete it as you say.
[23:26] <wgrant> 'delete'
[23:26] <lifeless> anyhow, what I want to achieve is the following:
[23:26] <lifeless>  - I want james_w's script to cleanup ubuntu package imports to work
[23:27] <lifeless> maxb: around?
[23:29] <wgrant> sinzui: What is the status of your mailman QA?
[23:29] <sinzui> lifeless: I do understand. we need to move th pre-delete rules into the model, and let the user choose to use them. What would be nice is a way to automatically deduce dependencies. Deleting the s-m-r-f chain took a lot of landing to fix rare cases like private and conjoined bugs
[23:30] <sinzui> wgrant: I do not have syncage: https://qastaging.launchpad.net/~test-list-sync
[23:30]  * sinzui made up a word
[23:30] <wgrant> :(
[23:30] <lifeless> sinzui: could you do me a huge favour? file a (low|high) bug about making this work, with your info, and mention its number in the one about delete oopsing.
[23:31] <sinzui> I I am landing the config fix now
[23:31] <wgrant> Otherwise we should be unblocked for deployment in a few hours.
[23:31] <sinzui> lifeless: okay
[23:31] <lifeless> sinzui: thank you!
[23:32] <bigjools> sample data I freaking hate you
[23:32] <wgrant> bigjools: :(
[23:33] <bigjools> the fact that it gets loaded after all the patches are run is awkward
[23:33] <bigjools> it means that I have to change it
[23:33] <wgrant> Ah.
[23:33] <wgrant> There are instructions for this :)
[23:33] <bigjools> since I have an evil plan to make version in the model class point at debversion in the db
[23:39] <leonardr> lifeless: right, it's either destroyed or not destroyed
[23:42] <poolie> leonardr, i'd love to talk to you about how wadl should be used by wrested some time
[23:46] <wgrant> Could someone please review https://code.launchpad.net/~wgrant/launchpad/bug-707741-addFile-master/+merge/47606?
[23:46] <wgrant> It fixes the rosetta-export-queue.py failure.
[23:49] <StevenK> wgrant: That looks good -- I think you should also check you can get the file out of the librarian, if you feel it's needed.
[23:51] <wgrant> slony please go away :(
[23:54] <wgrant> StevenK: Done.