[12:12] Right, I can wait till tomorrow. [12:12] In other news, changing the URLs is hell. [12:13] yeah [12:13] Because the context that used to be returned for the bug page was a bug, but now, I think, it needs to be a task, which breaks basically every portlet on that page. [12:13] bradb, I'll try to look at it tomorrow, but I can't guarantee [12:13] salgado: ok, thanks [12:14] mpt: Oh, btw, http://www.bikes.com/bikes/2005/sport/trailhead.aspx === Seveas [n=seveas@seveas.demon.nl] has joined #launchpad [12:19] mpt, you haven't been around the block much, have you? [12:19] nice little bike, bradb [12:19] kiko: Literally yes, figuratively no [12:20] kiko: thanks. I tend to read the consumer reviews *after* I buy something, but I often guess reasonably well. [12:26] kiko: Can I let the entire /malone/bugs namespace die? (i.e. so that /malone/bugs/$bug.id would raise a 404) [12:27] That way, I could commit to making all the portlets shown on the bug page work on the assumption that the context is an IBugTask [12:27] bradb: Probably 50~60 percent of the external links into Launchpad are to /malone/bugs/something [12:28] You'd have to redirect them somewhere [12:28] Where are the external links coming from? [12:28] Mailing list posts, Weblog entries, forums, etc [12:28] I haven't seen the referer logs, I'm just guessins [12:28] g [12:28] Yeah, I see some on Google [12:28] ff [12:29] Actually, few enough that I doubt it matters. [12:29] We're not even 1.0 yet. [12:30] is it very hard to just redirect them? [12:30] the question is where :) [12:30] Exactly. [12:30] We could just redirect them to the first context that we find that has the bug #, but why? [12:31] (i.e. Why bother with the extra complexity?) [12:31] because there is no better option? [12:31] 404'ing /malone/bugs/* seems like a better option to me. [12:32] well, since you're such a fan of Jakob Nielsen ;-) [12:32] http://www.useit.com/alertbox/980614.html [12:33] I even knew the date on that by hard [12:33] by heart, ARGH [12:33] mpt: Launchpad lives and breathes by linkrot, so far. [12:35] Anyway, redirecting or not, it sounds like I can still commit to never have a global, contextless bug page, right? [12:35] (That's the most important point for me, in terms of fixing every portlet to work with an IBugTask context on what is currently the "bug page") [12:36] I thought that was sabdfl's decision [12:36] (though I was also considering it as one possibility) [12:36] Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial] Fixes for three bugs. bug 1809: Incorrect Bugs facet link on PO template page (...+pots/something); bug 1808: Incorrect links in 'releases from this branch' portlet; bug 1807: Incorrect links in distrorelease's actions portlet. BjornT owes me beer (patch-2293: christian.reis@canonical.com) [12:39] Right, then I guess what I'll do is change the portlets in question to expect that the name "bug" be defined in their namespace, and have two pages, bug-index.pt, and bugtask-index.pt, which each define bug accordingly for the portlets to Just Work. [12:40] And wait and see what the sabster says. [12:50] Right, linkrot is bad. I hereby declare all Malone links immortal. [12:57] Thinking about it: should there be a syntax to access the LaunchBag in ZPT? [12:58] context/launchbag:bug, or something? [12:59] context/launchbag:product, context/launchbag:user, etc. [01:00] It seems to me that, if we have this magic bag of goodies, we might as well make use of it in as many places as it would make sense to do so (browser code seeming to be a place that it makes sense to do so.) [01:01] see you tomorrow [01:01] I believe this could simplify making the portlets that are currently shown on the bug page (and all the pages linked to from the bug actions porltets) Just Work, whether the context is a bug or a bugtask [01:01] s/porltets/portlets/ [01:01] kiko, mpt: Thoughts? [01:06] bradb, isn't the portlet now invoked with a specific context? [01:06] kiko: At the moment, it relies on its context being an IBug. [01:07] is that a problem? [01:07] yes [01:07] mpt: nope, back @ work [01:07] As per the reasons above [01:08] kiko: In the new URL scheme, the bug page will live at /products/foo/+bug/1, which means that the context becomes a task. === mpt loves crashes on baz commit [01:09] kiko: i.e. To the user, everything still looks pretty much like the good ole bug page (decorated, perhaps, with some new contextual information), but underneath, there's been a fairly major shift. [01:10] kiko: See what I mean? [01:17] bradb, just update the portlets to always take tasks -- doesn't that solve the problem? [01:18] kiko: That would break /malone/bugs/$bug.id (if we're intending for that page to continue to function as it does currently.) [01:19] I just want that page to be a redirect [01:19] if you can't do that, then I agree to nuke it away. [01:20] it wouldn't be too hard to redirect [01:21] I'll commit to the portlets counting on their context being a task, as per your suggestion [01:23] I think that's the best and simplest solution [01:23] So we're going to have /products/foo/+bug/1 and /products/foo/+bugs/1 ? === bradb shrugs [01:23] that is such crack [01:24] +bug is crack-o-dementia, but I just work here... [01:25] Well, maybe we can quietly redirect the former to the latter at some point [01:25] bradb, can we skip +bug for now, in a last ditch effort? [01:26] kiko: 3 against sounds good to me. [01:26] how hard is it going to be to change it to +bug later? [01:26] kiko: skip +bug in favor of what? [01:26] +bugs [01:27] So you're signing on to merging the bug and task pages? [01:27] huh? [01:27] bradb, can you help mpt :) [01:27] mpt: there's also +viewstatus and +editstatus [01:27] kiko, the task page is currently at +bugs [01:27] mpt: i.e. there will be [01:28] so, .../+bugs/1 => contextual bug page, .../+bugs/1/+{view,edit}status => what is currently the task page [01:28] oh, ok [01:28] So where normal bugtrackers have one page for a bug, we have three [01:28] but that's fixable [01:28] That seems relatively sane, IMHO. A .../+bug/1 flying out of nowhere was the most crackish bit, to me. [01:29] ok, I'm getting 15 errors on make check, which don't seem to be anything to do with me [01:29] mpt: No, we'll continue to only have two, but in fact, we don't have only two, we have about 10. [01:29] ProgrammingError: ERROR: relation "person" does not exist [01:29] SELECT defaultmembershipperiod, defaultrenewalperiod, timezone, calendar, teamdescription, password, subscriptionpolicy, teamowner, merged, displayname, givenname, name, familyname, datecreated, karma FROM Person WHERE id = 1 [01:29] mpt, that usually means that one test failed and then the rest bombed out after it [01:30] what's your first test failure [01:30] well, that's the first one [01:30] mpt: well "two", where there's actually a third in there, but it's a view/edit thing, and you'll only see a link to one or the other at a time [01:30] called by Failed example: print Person.get(1).name [01:30] line 58, in test_zopeless_reconnect.txt [01:31] bradb: for which JavaScript can save us [01:31] the view/edit bit is besides the point here [01:31] bradb, at worse, you can just make +bug be an alias for +bugs and change the links, shouldn't be too hard, right? [01:33] kiko: Would I be right in concluding that the database isn't working at all? [01:35] kiko: Making +bug/1 and +bugs/1 traverse to the same thing is very trivial. [01:35] DOIT [01:36] bradb, right -- then you can fix the links later and say "oh, I forgot" :) [01:38] heh === bradb DOES IT [01:39] o/~ giving him drugs o/~ [01:39] kiko? [01:40] music [01:40] File "/home/mpt/ubuntu/launchpad/lib/canonical/database/ftests/test_zopeless_reconnect.txt", line 122, in test_zopeless_reconnect.txt [01:40] Failed example: time.sleep(1) [01:40] Differences (ndiff with -expected +actual): - thread after execute - thread end [01:40] That's probably a more informative example [01:41] I don't worry about failures in those reconnect thingies [01:41] that's crack, mpt, ignore it [01:41] Well, ok, but that still leaves me with 14 database-y failures [01:47] oh, some of them are actually my fault [01:48] can anyone check in the database for me if Luxemburguish has plural forms data already? === mpt sulks [01:51] apparently it is [01:53] jordi: Just try translating something into Luxemb[o?] urgish and see if Rosetta complains [01:54] bradb, you should use macros a LOT more than you currently do [01:54] the code in bugtask-assignee-widget could be made 5x shorter [01:54] and I hate fixing the same bug 3x [01:59] kiko-zzz: Indeed. === spiv [n=andrew@home.waugh.id.au] has joined #launchpad [02:13] mdz_: I dd that, seems to be god [02:13] now, why am I getting this system error [02:15] jordi: eh? [02:22] mdz_: launchpad. It is so broken. :) [02:22] mdz_: actually, it seems I still have this ability to break it very well. [02:22] jordi: why are you telling me? ;-) [02:23] uh. [02:23] s/mdz_/mpt/g, who left the channel [02:23] mdz_: POP THE TRUNK [02:23] I'm going to bed. [02:23] jordi: that's more like it [02:24] bradb, ping? [02:24] kiko-zzz: pong [02:24] bradb, I found a bug in the assignee widget [02:24] are you ready for it? [02:24] Sure. [02:24] click on assign [02:25] assign to foo.bar [02:25] (click on edit, gah) [02:25] click save [02:25] you're teleported and foo.bar is the owner, right? [02:25] now click on edit again [02:25] don't change anything [02:25] click save [02:25] you aren't tp'd, yeah, i know [02:26] tp'd? [02:26] teleported [02:26] It's a simple fix, maybe. [02:26] no [02:26] that's not the bug [02:26] the bug is that you /are/ tp'd [02:26] AND [02:26] what's the issue then? I can't look right now, because I broke the URLs. [02:26] the assignee is unset [02:26] the reason is that you are using the same name for both inputs [02:26] assigned_to === asgeirf [n=asgeirf@nat-pool-brisbane.redhat.com] has joined #launchpad [02:26] I'll fix it for you tomorrow, anyway [02:27] Argh, I totally fixed that problem, but I guess I only fixed one aspect of that problem (i.e. using the same name for both radios) [02:27] the fix is to use different names, really [02:27] yeah, normally, it should [02:27] assigned_to and assign_to [02:27] but we can fix that tomorrow [02:27] was just a heads-up [02:28] ok, thanks [02:28] I even have two different names defined for them in parts of that template and as attributes on the view class (view/assigned_to and view/assign_to), but I guess that was a code path I didn't test. [02:31] for that matter, looking at the template code, it's unclear to me how they're ending up with the same name, but anyway [02:36] bradb, where is assignedToCurrentUser defined? [02:36] kiko-zzz: on BugTaskAssigneeWidget [02:37] aka, ctrl-] [02:37] thanks [02:38] I think I found the error [02:38] kiko-zzz: What's causing it to have the same name? I can see no reason here for why that should happen. [02:38] yep [02:38] it doesn't actually have the same name [02:39] it's missing a clause [02:39] because YOU ARE NOT CODING PROTECTIVELY! === kiko-zzz kicks bradb [02:39] look at getInputValue [02:39] I see an elif at the end of the branch [02:40] and NO raise AssertionError in an else clause (or at the end of the function) [02:40] may this never happen again! [02:40] ah, yeah [02:41] I'll fix it for you tomorrow for free [02:41] if you do a fast r=bradb afterwards :) [02:41] An untested code path, ultimately (despite the fact that this is problem the mostly thoroughly tested custom z3 widget mankind has ever known) [02:41] s/problem/probably/ [02:42] we're going to have to use a hidden input if we want this to be fixable trivially [02:42] argh [02:42] or maybe not [02:43] indeed, no need for a hidden field, i don't think [02:45] fixed [02:45] kiko-zzz: btw, where did you add