[00:47] ok, going quiet to get code written [01:09] awesome.. bzr branch of lp:launchpad ... 10 minutes and counting [01:09] 271502kB 1130kB/s | Fetching revisions:Inserting stream:Done 1297115/1297115 [01:11] Only 10 minutes? Not bad. [01:11] still not done ;) [01:11] It's nearly done. [01:12] Here it takes like 2 hours. [01:12] 28952 clint 20 0 777m 693m 3820 R 100 17.6 9:49.48 bzr [01:13] LP's history is not small, and bzr 2a fetch is not fast :( [01:15] well 12 minutes wasn't so bad [01:15] $ du -hs [01:15] 298M . [01:15] That's remarkably good. [01:15] considering.. :) [01:15] Are you in the DC or something? [01:16] No, I have a 12Mbit downstream tho [01:16] * SpamapS hugs his cable [01:16] I have 20Mbps downstream, but can't get more than 180KB/s from most parts of the DC :/ [01:16] Except to canonistack, where I can saturate my connection. [01:17] Just to confuse things. [01:17] Oh I was definitely saturating the 12Mbit [01:17] Some days I can't get 512kbit [01:18] but today has been really fast [01:18] * SpamapS now begins the task fo figuring out how to populate an unbuilt distroseries via the API. [01:19] You want to create a new charms series, I guess? [01:19] What do you want to populate? [01:20] Phew. germinate 2.1 released, MP updated, IMO all good bar the shouting now. [01:20] Shouting? [01:21] About three times the speed of the current implementation, on mawson anyway. [01:21] http://dictionary.cambridge.org/dictionary/british/all-over-bar-the-shouting [01:22] Ah. [01:23] Although it wouldn't surprise me if somebody wanted to shout at me about some bits of the test code. :-) [01:24] wgrant, i think there is something odd in the network [01:24] when we measured a while ago we saw substantially faster downloads from another dc machine than from lp itself [01:24] which is a bit perverse [01:26] poolie: I have an RT ticket open. [01:26] I was going to blame Optus until I saw that I could download at full speed through the same route up to the DC, except to Canonistack. [01:26] So unless they're throttling some Canonical /24s and not others, when I've never had any evidence that they're throttling specific ranges at all.. [01:28] we've measured the same effect from the US [01:29] Huh [01:29] I've seen some slowness from elsewhere. [01:29] But never as slow as I see. === jtv is now known as jtv-eat === jtv-eat is now known as jtv === jtv changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jtv | Critical bugtasks: 3*10^2 [03:51] wgrant: any chance you could help this user? https://answers.launchpad.net/launchpad/+question/181066 [03:52] jtv: Could you ask them to retry? [03:52] I can, yes. Do they need to bump their version number? [03:52] As you may be aware, the last 14 hours have been roughly disastrous. [03:52] No. [03:52] 14 hours? I heard there have been problems, but wow. [03:53] It's all been fixed for a couple of hours. [04:20] huwshimi: Could you QA https://launchpad.net/bugs/894535? [04:20] <_mup_> Bug #894535: Bug listing arrows appear to be backwards

< https://launchpad.net/bugs/894535 > [04:26] wgrant: Done [04:26] huwshimi: Thanks. [05:01] poolie: is your new bug a dup of 894535? [05:02] about the order? [05:02] no i'm talking about the horizontal order [05:02] i would expect the headings to be in the same order as the data cells :) [05:10] ah, there is a different 89* bug about that [05:16] Mmm, unused portlets. [05:16] * wgrant destroys. [05:31] right, time to EOD. [05:31] * lifeless EODs [05:32] Night lifeless. === jtv1 is now known as jtv-eat [06:37] The new https://bugs.launchpad.net/launchpad is a welcome change [06:37] Yep [06:38] One of the most annoying pages in LP has finally met its demise :) [06:39] :D [06:40] Unfortunately the new listings leave me disappointed when I click on a bug, and the old BugTask:+index kicks me in the face. [06:40] With the old status/importance styles etc. [06:41] wgrant: to answer your earlier question.. I want to populate the 'charm' distro's new series, 'precise' with all the branches from 'oneiric' [06:41] SpamapS: there's branch-distro.py to do that server-side, but it might not do exactly what you want. [06:41] Depending on how you want branches to behave between series. [06:42] well I'm thinking that I want them to just be their own thing.. [06:42] I will write a script which auto-proposes merges when the branches diverge.. [06:43] Most changes to the 'precise' charms will be useful in the 'oneiric' charms.. but I think we're going to have to just manage them as branches. [06:43] auto backporting won't work without something like tarmac verifying that the new charm works on the old OS [06:44] wgrant: so if I read branch-distro.py's underlying code right.. it just copies all the branches from one series to the next. That sounds like what I want. [06:44] SpamapS: Heh, sort of. [06:44] Effectively, yes. [06:44] But it moves the branches to the new series, then creates fresh ones in the old series, stacked on the new series. [06:44] I get that the old branch becomes stacked on the new one. [06:45] To the user it just appears that they've been copied, right. [06:46] If our workflow becomes commit to old branch, merge from old branch to new branch.. I don't see that as being problematic. [06:46] I think branch-distro would work for you. [06:46] so I just need a LOSA to run that for me? [06:47] Once you're that's what you want, yep. [06:47] Once you're *sure* [06:47] I kind of want to have them try it on staging and see what it looks like. ;) [06:47] staging doesn't have the branches on-disk, so that won't work. [06:47] Hmm.. that new bugs index was not rolled out under a feature flag [06:47] wgrant: I still see the bug listing arrows backwards, I did a forced refresh as well [06:48] micahg: Can I see a screenshot? [06:48] wgrant: the one thing I'm concerned about is I'm not ready for the dev-focus to be changed to the new series. [06:48] sure [06:48] huwshimi: No. Is that a problem? [06:49] wgrant: I just expected it to be part of the new bugs listing beta. It's a fairly big change, I guess someone will blog about it later or something [06:49] huwshimi: It's not a huge change. It's basically just expanding the listing and changing the default sort order. [06:49] Which AFAICT nobody liked anyway. [06:50] I will be surprised if we hear a single person complaining. [06:50] wgrant: also I can't "initialize" the series because this is an unpublished distro. [06:51] wgrant: I'm guessing that there's another script which will do that. [06:51] SpamapS: Right, it doesn't make sense to initialise an unpublished distribution. [06:51] wgrant: I guess [06:51] Initialisation copies the packages. [06:51] wgrant: I guess it's not like everyone reads the blog anyway [06:51] OH [06:51] wgrant: Still I would have thought it's big enough change for people to wonder why things are different [06:52] huwshimi: Mmm, we don't normally blog about this sort of thing. [06:52] wgrant: http://people.ubuntu.com/~micahg/bug_listings.png [06:52] Or we'd have a very, very noisy blog. [06:52] micahg: That's correct. [06:52] micahg: Check Nautilus, for example. [06:52] wgrant: so when I'm ready.. how would I change https://launchpad.net/charm/precise to the active dev series? [06:52] The arrow points in the direction of increasing value. [06:52] SpamapS: That probably requires a Launchpad dev/admin. [06:52] wgrant: that's how it was before :P, that's why I filed the bug [06:53] To change the status. [06:53] ahh [06:53] wgrant: Don't we? We blog about a lot of trivial changes [06:53] eg. I tend to do it for Ubuntu. [06:53] huwshimi: Recently, yeah. [06:53] micahg: Do you have an example of an application doing it the other way?" [06:53] Increasing usually mean in ascending order [06:54] micahg: Right. Critical > High, so Critical should appear higher than High when the arrow is pointing up. [06:54] no [06:54] ascending importance should mean critical last [06:54] micahg: Increasing in statuses means going from undecided > Critical [06:54] right [06:54] micahg: Sure, but arrow pointing up is descending, not ascending. [06:55] huh? [06:55] * wgrant points at Nautilus and probably everything else. [06:55] is everything upside down on the other side of the world? [06:55] Thunderbird as well. [06:55] * micahg goes hunting for proof [06:55] micahg: The arrow follows the content on the page [06:56] gah, still seems counterintuitive, idk why I never caught it in thunderbird before [06:56] micahg: Ordering by bug number might help you to visualise it [06:56] no [06:56] It does seem somewhat counterintuitive. [06:57] But it's how everything else seems to do it. [06:57] * micahg translates the arrow to ascending/descending which is probably the issue [06:57] Exactly. [06:57] * micahg checks HIG [06:57] arrows are a terrible way to denote sort order.. [06:57] .oO would be better [06:58] arrows imply direction, but not origin [06:58] micahg: bug #1 is at the top of the page down to #100 at the bottom so the arrow is pointing down, when #1 is at the bottom of the page and #100 is at the top the arrow points up. Both of these follow the direction of the content [06:58] <_mup_> Bug #1: Microsoft has a majority market share _mup_: Shhh [06:59] huwshimi: right, that's what I take issue with :) [07:00] micahg: Which browser are you using? Your fonts are ugly and misaligned. [07:00] firefox 9 beta [07:01] Hm, does it have any subpixel rendering at all? [07:01] wgrant: it should, but I might not have my display configured properly [07:02] huwshimi: wgrant: the HIG in 6.14.1 seems to agree with what you've done, so I'll resign myself to being confused: http://developer.gnome.org/hig-book/3.0/controls-lists.html.en#controls-lists-sortable [07:02] GNOME HIG that is [07:02] I was confused initially, don't worry :) [07:02] Probably because I mostly use sortable columns in Thunderbird, which defaults to the *bottom* of the list. [07:03] right, I'm just used to ignoring the arrows in thunderbird I guess [07:03] since I sort once and forget it [07:03] * micahg seems to agree with gnome 305277 [07:04] * micahg guesses mup isn't ubottu :) [07:04] https://bugzilla.gnome.org/show_bug.cgi?id=305277 [07:05] micahg: When you reported the bug there was actually a bug which meant the direction of the arrows was not consistent for ascending or descending which probably didn't help [07:06] huwshimi: that's not why I filed the bug though :), I guess I didn't notice that since it was counterintuitive to begin with [07:08] micahg: The Code was supposed to be in the opposite direction of what it is now (so, apart from the bug, it was originally in the directions your bug report wanted them to be) [07:12] :D === almaisan-away is now known as al-maisan === jtv-eat is now known as jtv [08:53] good morning === al-maisan is now known as almaisan-away [11:12] cjwatson: hope you don't mind the piecemeal review style. I was also on call for other things today, so this was a way to mitigate risk of distraction. [11:20] jtv: that's fine, I'm just trying to keep up. :-) [11:20] :) [11:20] jtv: hope in turn you don't mind lots of piecemeal commits to fix things [11:20] I see you already restructured runGerminate. [11:20] No, that's fine. [11:21] It makes it a bit harder to follow but turnaround's fair play. Plus, it's fun to see the changes happening! [11:21] Still in progress on that. I'm trying to sort out the inner body first and then figure out how/whether it should be split up further. [11:23] The closure question is a bit difficult. I'm trying to balance clarity there against having methods with too many arguments. The functional programmer in me likes closures, but they don't seem to result in awfully clear Python sometimes. [11:24] ISWYM. It's a tough tradeoff. In a functional language you don't have assignments to worry about. [11:25] And a class is probably overkill. [11:25] I actually want curried functions for composeOutputPath, really ... [11:25] Yeah. :) [11:26] ISTR there being a bind() in the python standard library somewhere, but have always been too lazy to look it up. [11:26] So I'll simplify everything else and see how it looks. [11:26] functools.partial? [11:26] That'd have to be it. [11:27] Interesting, quite a few callers in LP already. I'll look up house idioms. [11:27] It's very handy. [11:27] BTW, unrelated tip, for makeSeedStructure in the tests: instead of “if seed_name in seed_inherit:” you could probably have a single code path with seed_inherit.get(seed_name, []) [11:29] Neat! test_name_is_consistent & test_name_is_unique_for_each_distro [11:30] .get> oh yes. [11:30] Can't claim credit for that; that was stolen from test_generate_contents_files. [11:31] It did sound familiar. I think I wrote that. :) [11:31] Nice to know you like your own code. ;-) [11:41] cjwatson: I must admit that, knowing that, my comment about the high quality of the branch seems a bit self-serving in retrospect. :) [11:45] Heh. I mostly just used it to fill out an initial skeleton; I'm still unfamiliar enough with Launchpad that cargo-culting is a good strategy to get me started. [11:45] morning [11:56] cjwatson: I guess most of the test_germinate_output_task tests could be unit tests for an extracted “calculate output task” method. It would save a lot of setup. But it's useful of course to have at least one test that does do all of that and tests the integration of a larger scope of the code. [12:05] * jtv watches the code break into smaller parts === jtv changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugtasks: 3*10^2 [12:08] jtv: Yep, that's more or less what I did [12:11] jtv: Oh, I think the reason I wrote makeSeedStructure that way was that I didn't want the trailing space in the no-inheritance case; that meant that I could just do a straight file comparison with the output. [12:11] jtv: It got a bit twisty when I tried to use .get. [12:12] ("%s: %s" % (seed_name, seed_inherit.get(seed_name, []))).strip() or something [12:22] cjwatson: Or just treat the "%s:" % seed_name as one of the elements of the list, I guess. [12:23] " ".join(["%s:" % seed_name] + seed_inherit.get(seed_name, [])) ? [12:23] Also a bit involved, I must admit. [12:40] jtv: on open(path).read(), Julian criticised a previous branch of mine where I did that in tests and asked me to use 'with' instead [12:40] jtv: https://code.launchpad.net/~cjwatson/launchpad/i18n-index/+merge/78618 [12:40] * jtv reads [12:41] "critiqued" :) [12:41] well, OK :-) [12:41] context managers ftw [12:42] Don't file handles get GC'd? [12:42] eventually, context manager make sure it happens on exit [12:42] well, exit of the block you use it with [12:42] In this case, “eventually” is fine AFAICT. [12:42] good habits and all that [12:43] If you neglect to do it while writing, python will generally punish you very quickly. [12:44] I don't hugely mind either way in this case, but it does seem odd to be told to change A to B by one reviewer and B to A by another, so maybe some consistency would help. :-) [12:44] (I agree there doesn't seem a desperate rush to close the handle, but whatever) [12:45] it's not the tardy GC as such, it's the open file [12:46] But doesn't the GC also close the file? [12:46] yes - but when? [12:47] Soon enough, evidently. [12:47] You might imagine a situation where tests churn through file handles fairly quickly and the GC doesn't get round to dealing with them until you run out of file handles. [12:47] Whether that actually happens in practice I don't know. [12:47] ARGH fucking cached WADL [12:48] The system limit is typically large but not enormous. [12:49] Python might even detect the situation and do an extra GC. [12:49] cpython closes it (pretty much) immediately, but other Python implementations (notably pypy) might take a while. [12:49] it's better to be explicit IME [12:49] Everything other than CPython is unreliable. [12:50] You're meant to close explicitly. [12:50] (and it's just so easy to do it with context managers nowadays) [12:50] And, for clarity, that is *fine*. [12:50] The Python spec doesn't say anything about this. [12:50] Sure. [12:50] Crazy cat. I just let you _in_. [12:51] So it's up to the implementation to make this decision. [12:51] Well, "Python spec" [12:51] lol [12:51] *g* [12:51] fsvo [12:51] wgrant: The only spec I trust is written in C :P [12:51] Heh [12:52] but haven't you heard, pypy is fast :) [12:52] Anyway, Jython, IronPython, PyPy all have more sane GC processes than CPython. I suspect all alternate implementations do. [12:52] And considering how PyPy will hopefully rule the world in a couple of years... [12:52] That takes me back to my JVM programming days. "You caught us. No it doesn't really work like the spec says. But we have a solution for that: we call our code the spec, and not the thing we publish as the spec." [12:53] I want to make a new Python interpreter and call it TrouserSnake [12:53] Him and his dirty mind. [12:53] so debugging question for you all, if I had a pair of ids for Message objects, and I wanted to "see" them to find out wtf they were and maybe compare how they were different. How would I get at them? Normally I'd expect to just look at the db, but this is on production [12:54] In some languages(*) python already means trouser snake. There's instances of Python websites being censored because automated translation software says they could have naughty things on them. [12:54] rick_h_: put together a query, ask an admin to run it against a production slave? [12:54] rick_h_: Oh, you are looking at that NoCanonicalUrl bug, aren't you... [12:54] Not a good thing to start on :) [12:54] wgrant: yes [12:54] heh, well originally we thought it was something where I could see how iMessage was used [12:55] bwahahah [12:55] Several people have looked at that and failed, IIRC> [12:55] wgrant: but now I'm stuck digging at how half the url, lazr restful, and all that works [12:55] Yeah... [12:55] wgrant: ok, well now I don't feel bad I didn't just *figure* it out yesterday afternoon [12:56] I think we may be getting a raw Message out where we're meant to have a BugMessage. But it's been a good year since I last looked. [12:56] ok, but this is good, I'll finally poke at the database and maybe figure out how to generate a query to be run [12:56] that'll be fun [12:56] wgrant: yea, the thing I notice is that the failing one has a patch on it [12:56] You'll most likely fail, but you'll learn lots about our infrastructure :) [12:56] wgrant: so I'm wondering if somehow the patch has a url/path getting generated? [12:57] wgrant: yea, I guess the goal is for me to learn parts of the system and I can do that in failure. But man I hate failing... [12:58] but my goodness is this whole url generating stuff convoluted. It's interesting to work on a project where I can't just download the prod db and fire in debug code/debugger steps [13:03] Hmm. [13:03] I think I know what it probably is. [13:03] cjwatson: you have been reviewed. I'm off for food now, before I start hunting for those crickets that I'm hearing like the cat does! [13:03] rick_h_: The message probably has a parent that isn't a comment on the bug. === jtv is now known as jtv-afk [13:04] wgrant: yea, that's what I was kind of curious about. I see the stuff that iterates through the url looking for more parts to generate and curious how this comment differs from the one before/after which work [13:04] jtv-afk: Yay, thank you. I'll go hassle folks about the deployment steps ... [13:05] rick_h_: So, I can confirm that in this case the exception is generated about comment #11's parent message. And that parent message is not a comment on the bug. [13:05] Not a comment on any bug, in fact. [13:05] THat might help you reproduce it locally.; [13:06] jtv-afk: I found a way to write makeSeedStructure that avoids multiple paths without being too twisty, I think. [13:07] wgrant: ok, interesting. thanks [13:07] wgrant: hmm, when I check each comment's parent attrib via the api I get None for all of the comments [13:08] wgrant: different "parent"s? [13:08] rick_h_: That's the only message on the bug with a parent. [13:08] Only comments that were emailed in have parents. [13:09] wgrant: how did you see it had a parent? [13:09] I'm magical. [13:09] And have access to dogfood's DB. [13:09] Which is a 2.5-month-old snapshot of prod. [13:09] wgrant: strage that the api says it has no parent, but the db says so [13:10] I always knew wgrant was magical :D [13:10] rick_h_: Hm? The API doesn't say it has no parent. It crashes when trying to say that it *does* have a parent. [13:10] AFAICT [13:10] wgrant: right, but if I launchpad.bugs[805938] and print parent for m in bug.messages I get None for all, including 11 [13:11] rick_h_: Ahh [13:11] That's different. [13:11] Evilly different. [13:11] wgrant: hmm, actually I show (via that api stuff) that comment 7 has a parent of comment 6 [13:11] That uses a special property (Bug._indexed_messages or something) to precache the parents. [13:12] rick_h_: Bah, yeah, you're right, I missed one. [13:12] wgrant: ah, ok I saw that stuff somewhere [13:12] 7's parent is 6, 11's parent is some other random message somewhere. [13:12] Not on any bug. [13:12] wgrant: when it tries a couple of methods to generate the CanonicalUrlData it tries the cache and then if that fails generates one I think [13:12] Possibly on a mailing list or something. [13:23] rick_h_: Aha [13:23] wgrant: more magic kicking in? [13:23] rick_h_: The problem is indeed what I said, and it's in _indexed_messages. [13:24] No more magic, no. [13:24] if parent is not None: [13:24] # If there is an IndexedMessage available as parent, use [13:25] # that to reduce on-demand parent lookups. [13:25] parent = message_by_id.get(parent.id, parent) [13:26] So, if the parent is a comment on the same bug, it will replace the BugComment's parent Message with the corresponding BugComment. [13:26] BugComments have URLs. [13:26] But if the parent is *not* a comment on the same bug, the parent will remain as a Message, which has no URL. [13:26] boom. [13:26] wgrant: right, gotcha [13:27] wgrant: ok, that makes sense since I could find no way to build a url to a message (was looking at that vs trying to hit the db quuery) [13:27] Best way to solve this is probably just to say the parent is None in that case. Since messages don't have URLs. [13:27] Since they may be referenced in many places. [13:27] eg. I can send one email to 200 bugs, it will be stored as one Message. [13:27] wgrant: orly, interesting [13:28] At least that's how it's meant to work -- if the content and message-id are the same, it's meant to only store one copy. [13:28] yea, I see that it stores the email id in the row [13:28] so a Message can be either an email or form entered text? [13:28] Right. [13:29] In the case of an email, we parse In-Reply-To, look up the corresponding Message, and link it up with Message.parent. [13:30] now could the parent be something else that *does* have a url? [13:30] or is the parent always another message? and if it's a message it's either a bug/url-able or an email (which is not urlable) [13:30] The parent is always another Message. [13:30] and excuse my indicision on if url-able is hyphenated or not :) [13:30] URLable? :) [13:32] rick_h_: it's urlificable, obviously [13:32] * wgrant should sleep. [13:32] * rick_h_ smacks head [13:34] rick_h_: https://bugs.launchpad.net/launchpad/+bug/901124 and https://bugs.launchpad.net/launchpad/+bug/901122 have generated several complaints today -- the new bug listings cause pretty much constant timeouts on large Ubuntu bug searches. Can someone from your squad look at these pretty urgently? [13:34] <_mup_> Bug #901124: New bug listings get length of collection twice < https://launchpad.net/bugs/901124 > [13:34] <_mup_> Bug #901122: New bug listings need to preload more attributes < https://launchpad.net/bugs/901122 > [13:34] wgrant: I'll bring them up at our stand up in an hour [13:34] Thanks. [13:42] matsubara, Are you able to, easily, calculate the median len of a bug title? If not, I'll use your data to calculate one. [13:43] mrevell, I can give it a shot. My SQL knowledge isn't that great [13:43] * matsubara looks for postgresql docs [13:44] matsubara, Oh, hey, I was just going to pop the data in a spreadsheet and then organise it into columns. Don't worry, I'll just do it. [13:44] http://plusplus.wordpress.com/2009/11/18/finding-median-with-postgresql/ [13:44] matsubara: ^ [13:44] mrevell, ok [13:44] rick_h_, thanks! === matsubara is now known as matsubara-lunch [14:34] deryck: https://bugs.launchpad.net/launchpad/+bug/901124 and https://bugs.launchpad.net/launchpad/+bug/901122 [14:34] <_mup_> Bug #901124: New bug listings get length of collection twice < https://launchpad.net/bugs/901124 > [14:34] <_mup_> Bug #901122: New bug listings need to preload more attributes < https://launchpad.net/bugs/901122 > === abentley changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: abentley | Critical bugtasks: 3*10^2 === matsubara-lunch is now known as matsubara [15:45] stub: hey [15:45] abentley: there are some differences between the names of display flags like "show_last_updated" and related sort parameters, like date_last_updated, while other names "relate better", for example "show_assignee" (display flag) and "assignee" (sort parameter), where one can simply add/remove the prefix "show_". Would something explode if I change the flags in templates/buglisting.mustache and in BugListingConfigUtil.field_display_names so [15:46] flacoste: apologies for the TL meeting; will be getting a CT scan of my sinuses [15:46] lifeless: ok, sleep weel in the mean time :-) [15:46] flacoste: EBABY :P [15:46] gary_poster: since you are hosting ^^^ [15:46] adeuring: You cut off at "and in BugListingConfigUtil.field_display_names so" [15:46] flacoste: 0446 now, had alarm set for 0550 to get up anyhow, as its a bit of a drive [15:47] abentley: ...so that all "show_" names match corresponding sort options? [15:48] adeuring: Nothing will explode, however, I think that we should try to make our internal names match the external names. [15:48] "Last updated" is the text we're currently using. [15:49] abentley: I see your point-- but "correlating" the sort buttons and the "show_.*" flags is in this case a bit messy... [15:50] abentley: and "show_id" does not match "Bug number" that well ;) [15:50] (in a very literal sense...) [15:52] Is it a matter of the sort buttons or of the terminology used by orderby? [15:52] sinzui: got a few moments to chat? [15:55] abentley: the code that shows/hides the sort buttons needs to have an idea about the relation between sort parameter names (fixed) and the field to display. I am curtrently "translating" for example betwwen "bug_heat" (display flag "show_bug_heat") and the sort option "heat". That's ugly and error prone [15:55] allenap: you say to see the bug report for details, but the bug report says 'we should talk' :P [15:55] lifeless: I wonder if I linked to the wrong bug :-/ [15:57] adeuring: But it also seems like you're reluctant to change the name of the sort option "heat". I am guessing you are reluctant because it's used directly by orderby. Is that right? [15:57] allenap: https://bugs.launchpad.net/storm/+bug/887240 [15:57] <_mup_> Bug #887240: test_terminated_backend test failure < https://launchpad.net/bugs/887240 > [15:57] lifeless: Yes, I did, and my branch name is all wrong. [15:58] lifeless: https://bugs.launchpad.net/psycopg/+bug/900702 is the correct bug. [15:58] <_mup_> Bug #900702: pgbouncer error in test suite, psycopg went psycotic < https://launchpad.net/bugs/900702 > [15:58] Sorry. [15:58] abentley: yes, that would affect quite old code in the class BugTask, for example, including the need to have aliases for old sort names. People may have bookmakrek URLs with "?orderby=heat" [15:59] lifeless: yo [15:59] stub: categorising patches [16:00] stub: I think adding a suffix would do it simply enough - patch-2011-44-0-concurrent.sql [16:00] (meaning all nodes no xact) [16:00] options being std, direct, concurrent [16:01] lifeless: Or subdirs or something like that - yer. [16:01] stub: then the upgrade can do all ordered patches from $ next to apply up to the first type change. [16:01] stub: how does that sound? [16:02] adeuring: That's what I thought. [16:03]