[04:00] StevenK: rvb has two pending items on https://devpad.canonical.com/~lpqateam/qa_reports/deployment-db-stable.html -- could you please try to QA those? === wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs:208 - 0:[######=_]:256 [04:03] wgrant: the work you are doing on product picker - have you made any changes to ProductVocabulary in vocabularies.py? [04:03] Project windmill-db-devel build #364: STILL FAILING in 1 hr 7 min: https://lpci.wedontsleep.org/job/windmill-db-devel/364/ [04:04] wallyworld: Just http://paste.ubuntu.com/619573/ [04:06] wgrant: thanks. i'm looking at altering the json so that exact matches (or matches above a certain ranking) are returned in a separate attribute so that if there are "too many" we can stil display the exact ones [04:07] bug 255282 [04:07] <_mup_> Bug #255282: project name picker search / vocabulary is hard/impossible to use (too many results on exact searches)

< https://launchpad.net/bugs/255282 > [04:07] wallyworld: Probably better to limit? [04:07] wallyworld: That's what that diff does. [04:07] wallyworld: It ranks exact matches first, then by FTI, and limits as well. [04:08] wgrant: ah yes, i didn't see the limit [04:08] Limiting in the current implementation is bad, because it ranks by displayname. [04:08] in that case, that bug is moot [04:08] But ordering by rank makes limiting sensible. [04:08] yes agreed [04:09] i spent some time cleaning up a fix previously landed which didn't work properly :-( [04:09] Oh? [04:10] there was one recently to deal with the picker handling too many matches but it was all wrong (i didn't do the fix, just cleaned it up :-) [04:10] Ah, right, I remember that one. [04:11] wgrant: so i should assign that bug to you since your change deals with the problem [04:11] wallyworld: Probably, yeah. I think this two line change solves most of the product picker problems. [04:11] ok. you can link a few bugs to your branch :-) [04:12] Yup. [04:12] The prettification is a separate, more complicated beast. [04:13] wallyworld: The link doesn't seem to do anything. [04:13] The one you just landed. [04:13] And the spacing is off. [04:13] works for me? [04:14] your sure your browser is not blocking popups? [04:14] Which browser? [04:14] i use ff4 [04:14] Ew, popups? [04:14] well the browser says its a popup but it's a window.open(...) call [04:15] and i have mine set up to open in a new tab [04:15] Hm, then it shouldn't be green. [04:15] Green means an inline thing. [04:15] well, i was told to make it green [04:15] href is not defined [04:15] When I try it in Firefox 4. [04:15] green meaning "this link doesn't kill the current page" [04:15] ? [04:16] i'll have another look, but it worked when I tested before ec2'ing [04:16] Hmm. Where is href defined? [04:16] I think you might have meant data.alt_title_link [04:16] i need a bit more context. let me open the branch [04:17] window.open(href) is failing, since href is not defined. In the 'if (data.alt_title)' branch. [04:18] Anyway, it's all behind flags, so it doesn't really matter much right now. [04:18] that sucks. yes, it is broken. not sure how i let that happen. [04:18] i'll fix [04:18] Thanks. [04:18] We should also huwshimi about the link style, I think. [04:19] It looks a bit odd being in the parenthesised section. [04:19] sure. i'll do what i am told :-) i wanted to make it something different but was told the styles are fixed and not easily changed [04:20] Well, it's easier to change now it's there. [04:20] The hard bit is doen :) [04:20] yep [04:31] wallyworld: Did you intend to reuse the commit message? [04:31] I see you did that on lazr-js a few times too. [04:31] It's rather confusing. [04:31] probably should have changed it [04:32] didn't think you would be looking so closely at it [04:33] I read most diffs, so I can keep track of what's going on and hit people when they introduce security holes :) [04:36] fair enough :-) [04:36] Project windmill-devel build #171: STILL FAILING in 1 hr 10 min: https://lpci.wedontsleep.org/job/windmill-devel/171/ [05:22] Project windmill-devel build #172: STILL FAILING in 45 min: https://lpci.wedontsleep.org/job/windmill-devel/172/ === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [07:47] Who's up for a pre-imp chat? [07:52] Project windmill-db-devel build #365: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill-db-devel/365/ [07:59] lifeless: got another fun problem that I'd love to discuss with you — creating multiple Jobs in one query. [07:59] jtv: lifeless isn't here today. [07:59] Ah blast [07:59] jtv: But that's always fun. [07:59] Yes [07:59] I think you have to use strings. [07:59] That's what I do, at least. [07:59] eg. in PublishingSet.publishBinaries [08:00] You mean, SQL strings? [08:00] Ja. [08:00] That's not really the problem I'm pondering though. [08:00] I never really assumed that Storm would support what I wanted directly. The real questions is how to make this work well API-wise. [08:01] It seems easy: extend IJobSource with a createMultiple() that returns an iterable of job ids. [08:01] Then feed those into job-type-specific equivalents of createMultiple(). [08:02] The part I dislike is how some IJobSource-derivatives operate on Job, and classes implemented purely in that table; and others like to refer to other tables that in turn refer to Job. [08:03] So IJobSource.createMultiple() would end up in job utilities that are expected to return something else than Job. [08:03] I would like to delete 'Job' [08:03] You're not here. [08:03] Shoo. [08:04] its a generally poor pattern for sql to do inheritance like that [08:04] I pass through [08:04] Not using direct inheritance support in the DB does make things feel very awkward and old-fashioned, [08:05] almost like inheritance in JavaScript. [08:05] Maybe we should've just used db-native table inheritance. :) [08:06] well [08:06] I would have done code inheritance but not db inheritance [08:07] for most jobs there isn't anything in common, but we've created a bottleneck as it stands [08:13] :( [08:14] by analogy, why don't we have a base *table* with the id column :> [08:14] Indeed. [08:14] Also, why does the test suite and staging update take so long :( [08:15] And why does something conflicting with db-devel have to have just landed :( [08:15] The answer, my friend, is blowing in the wind. [08:16] lifeless: you're right though — design of our jobs is driven by commonality of contents, not commonality of purpose. [08:17] It'd be nice if we could at least have a pattern along the lines of "put everything in the json metadata, but we can also duplicate data that needs to be searchable in proper columns." [08:19] I think I need to keep multi-job creation out of IJobSource because it isn't even a utility interface; it's an interface definition pur sang. [08:22] good morning [08:24] hi adeuring [08:24] hi jtv! === henninge changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: henninge | Critical bugs:208 - 0:[######=_]:256 [08:53] wgrant: Hi, I'm in the progress of QAing r10636. [08:54] rvba: And r10641? [08:55] wgrant: yes, that too [08:55] Thanks. [08:55] rvba: Have you talked to Stevenk? [08:55] At length. [08:55] wgrant: Yes I have ... [08:56] Happy Monday [08:56] Heh [08:56] Hello mrevell! [09:11] Project windmill-devel build #173: STILL FAILING in 1 hr 10 min: https://lpci.wedontsleep.org/job/windmill-devel/173/ === jtv1 is now known as jtv [09:30] Project windmill-db-devel build #366: STILL FAILING in 1 hr 14 min: https://lpci.wedontsleep.org/job/windmill-db-devel/366/ [10:04] wgrant: hi [10:06] jelmer: Hello. [10:08] wgrant: you mentioned in #bzr you were QA'ing some of the bugs in my newer-bzr branch; are you still working on that and/or is there something I can help with? [10:09] jelmer: I tried a few things on qastaging, but I'll probably need to do importds on staging tomorrow, since qastaging doesn't have any. [10:09] (and it's not on staging yet) [10:10] * wgrant -> food [10:10] ah, ok [10:15] wgrant: if you need any help, you know where to find me :) === almaisan-away is now known as al-maisan [10:27] jelmer: Yup, thanks. [10:54] rvba: How's it going? [10:55] wgrant: good so far, I've found a bug. [10:55] wgrant: is this blocking you in any way? [10:56] rvba: This is potentially disastrous. [10:56] rvba: We need to merge db-stable into devel today. [10:56] What's the bug? [10:56] wgrant: a simple UI bug. [10:56] In +initseries? [10:56] yes [10:56] Ah, OK, fine then. [10:56] Nothing disastrous :) [10:57] I'd like to do the merge in the next 30 minutes. [10:57] To catch the next devel run. [10:57] So it'd be great if you could have the QA done by then. [10:58] Since the changes in question are (like always) derivation related ... I suppose we could mark these bug QAok. [10:58] s/bug/bugs/ [10:58] Well, they also have the potential to break Ubuntu initialisation, but yeah, that's a while off. [10:58] So if you can't get them done soon, qa-ok it is. [10:59] wgrant: that's right, they have potential to break ubuntu init ... I think StevenK is checking these changes very seriously. [11:02] StevenK: I suppose +initseries won't be used "for real" right now, the only dangerous thing is the initialisation of ubuntu. what is the conclusion of your conversation with Julian this morning about this? Will you check the ubuntu initialisation? [11:12] wgrant: We found another bug in initialisedistroseriesjob ... if you pass packagesets=None the job will fail because of the way parameters are passed inside a metadata attribute. [11:13] It will be very easy to fix but it's a stupid bug. [11:13] https://bugs.launchpad.net/launchpad/+bug/793434 [11:13] <_mup_> Bug #793434: Passing packagesets=None triggers an error when initializing a series. < https://launchpad.net/bugs/793434 > [11:15] wgrant: I suppose I should wait for you to merge db-stable into devel and then fix this in devel ...? === al-maisan is now known as almaisan-away [11:18] rvba: Probably, yes. We'll merge shortly, then be frozen until QA'd past the merge. [11:18] Which will be tomorrow some time. [11:19] Ok, I'll get the fix ready then. [11:20] Thanks. [11:31] rvba: So, can we qa-ok them? [11:31] wgrant: I *just* did. [11:31] Right in time I suppose ;) [11:31] Heh. [11:31] Thanks. === almaisan-away is now known as al-maisan [12:25] I wish make schema would do just exactly that, not a million other things [12:25] bigjools: I use 'make -C database/schema' [12:27] stub: do you know why the top-level Makefile's schema target depends on build then? [12:27] * henninge lunches [12:28] bigjools: Don't know. Technically that is correct I guess, since we need /bin/py built and stuff, so the problem is that 'make build' is too busy [12:28] Also that 'make build && make schema' re-does bits of the build [12:30] ah, that Makefile uses bin/py ... :/ [12:30] probably something to do with wadl depending on *.py... perhaps that should only rebuild if explicitly asked or if it is non-existent [12:30] jeebus, the test failure attachments are huge now [12:31] Yer... all those librarian logs... [12:31] and SQL now it seems [12:31] that I suspect are not reset between tests... [12:32] Hmm. [12:32] schema doesn't need build. [12:32] Just compile. [12:32] Which is much smaller, and runs OK with -j3. === wgrant changed the topic of #launchpad-dev to: devel is release-critical until r13163 deployable | https://dev.launchpad.net/ | On call reviewer: henninge | Critical bugs:208 - 0:[######=_]:256 [12:34] that was slower than -j2 last time I checked [12:34] ... bah. [12:35] What does 'orphaned' mean on the qa'd patch deployment report [12:35] ? [12:36] stub: You used [testfix] when you shouldn't have. [12:36] I decided it was safe to deploy, since it passed buildbot and seems harmless. [12:36] So it is in devel now. [12:39] staging seems happy enough, so if it's not OK please yell really really soon. [12:44] That branch lifelesslanded would be qa-untestable anyway. Nothing is using the new table yet, so the fallout would be in related areas that don't cope with the triggers. [12:51] stub: Yep. [12:56] have we got a run_jobs.py cronned in on staging? [13:05] hi henninge! Can I trouble you for a review? https://code.launchpad.net/~jtv/launchpad/db-bug-793382/+merge/63545 [13:05] * henninge tries not to let anything trouble him ... [13:06] Is that good or bad? :) [13:06] jtv: sure, I am happy to look at your review. ;-) [13:06] \o/ [13:06] good for me, saves me the troubling. [13:07] s/at your review/at your proposal/ [13:10] flacoste: Can I get an RC for https://code.launchpad.net/~gmb/launchpad/bug-772609-hopefully-without-breaking-anything-this-time/+merge/63432? It should have landed Friday night but bounced due to a [testfix]. [13:16] gary_poster: Morning. [13:17] morning wgrant [13:17] gary_poster: You're still planning to release the new subscriptions stuff during the downtime deploy this week? [13:17] or evening, sorry [13:17] (the bugmail footer change is in devel now, so will be deployed unless it's reverted) [13:18] (but we still have the strucsub listing regression, so I'm not sure) [13:18] wgrant, yes [13:18] Great. [13:19] (the structsub listing thing has branches to be addressed--that also rip out the feature flags--after at least a day or two of making sure that the subscriptions stuff is ok when exposed to everyone) [13:20] OK. We've only had a few complaints about its absence, so I guess it's not too bad. [13:20] cool [13:20] Despite the mild security implications. [13:21] wgrant, security? Do "other subscribers" affect visibility of private bugs? [13:22] gary_poster: No. But people inevitably mistakenly put private info in public bugs, and want to know who it was emailed out to. [13:22] Hopefully that's less common now. [13:22] ah, k. [13:23] gmb: Hmm, I'm not sure who can grant r-c these days. Since there's no RM... [13:23] Hmm. [13:24] Traditionally it was flacoste, lifeless or . So I guess we have to wait on one of the other two. Or maybe gary_poster can sign off on it. [13:24] This seems pretty clearly necessary and really wants to land in the next 3 hours, or I will be sad tomorrow. [13:24] Yes. [13:24] * gary_poster has vague memories of team leads having privs like this? [13:25] It hasn't been used since the RM position was abolished, [13:25] gary_poster: Let's say that your memories are right :) [13:25] Heh. [13:25] :-) [13:25] Because we are minimizing the stuff that *has* to rollout during downtime deployment. Does this come with a db patch? [13:25] gmb, ok, I'll go fiddle with the MP then [13:25] stub: No. [13:25] * gary_poster waits... [13:25] stub: Yeah, this is the issue with deploying features at the same time. [13:26] Which lifeless is vehemently against. [13:26] stub: But if stuff is rolled out without this, we will have breakages. [13:26] And that will make both wgrant and I go [13:27] This release prep is chaotic enough already, let's not make it worse by delaying this. [13:27] stub, barring your quick strong objection, I'll approve [13:27] Sure. Might want to make that clear to Francis and/or robert then [13:27] I don't object, not that it would matter if I did :) [13:28] heh, I dunno [13:28] I would wonder if not landing it could be worked around by just disabling the feature using a flag, which also isn't clear from the MP [13:29] gmb, rc approved with all the authority of my title behind it ;-) [13:29] Cool, thanks. [13:30] Its actually pretty awesome the last few releases haven't needed RC's... [13:30] Used to be a truck load of 'OMG its broken' fixes picked up by last minute QA [13:30] Well, given that we deploy stuff every couple of days, there's less space for stuff to explode. It's been working pretty well! [13:40] stub: wgrant: gary_poster: FWIW I think 'rc-approval' is fine from squad leads [13:41] I'm not sure we -need- an rc-approval bit other than 'this has to be landed to make the downtime safe' [13:41] cool, thanks lifeless [13:41] and agreed [13:41] a team review approval seems pretty good to me [13:41] this is fixing the anonymous viewing of bug pages right ? [13:42] gary_poster: re: releasing the new subscription stuff - thats slated for Monday right ? [13:42] It has to be Thursday, I think :/ [13:42] The bugmail footer change is not flagged. [13:42] why ? [13:42] So it will be deployed on Thursday. [13:42] Unless that page works for everyone? [13:42] lifeless, correct. we had the flag discussion on the bug tracker, I think [13:43] I think we should wait for an hour or two after the deploy before setting the flag [13:43] or monday per gary_poster's comment just now ;) \o/ [13:43] no no [13:43] I was agreeing with wgrant [13:43] ok [13:43] we can wait, but then there will be a couple of hours in which the links will point to a page without valuable info [13:44] page will appear [13:44] sure [13:44] but no info [13:44] lets just wait ~1 hour - enough time to see that nothing else is truely messed up [13:44] I'm fine with that [13:44] if something is, we can open the flag wide and know its not the flags fault [13:45] vice versa, if it looks good and we open the flag wide and it falls over, we know it probably is the flag. [13:45] anyhoo... its now late, so gnight all :) [13:45] sounds good lifeless. 'night === wgrant changed the topic of #launchpad-dev to: devel is release-critical until r13164 deployable | https://dev.launchpad.net/ | On call reviewer: henninge | Critical bugs:208 - 0:[######=_]:256 [13:47] Night lifeless. [13:49] Project windmill-db-devel build #367: STILL FAILING in 1 hr 7 min: https://lpci.wedontsleep.org/job/windmill-db-devel/367/ [14:00] adeuring, henninge -- ping for standup. [14:01] Project windmill-devel build #174: STILL FAILING in 1 hr 7 min: https://lpci.wedontsleep.org/job/windmill-devel/174/ [14:01] deryck: yup [14:02] X crash. Unity? [14:08] reboot, brb [14:22] mrevell, hi. are you going to be around to give some UI opinions in the next half hour or so if I send you some screen shots? [14:22] gary_poster, Yes, certainly. [14:22] mrevell, thank you [14:22] np :) [14:22] jtv: reviewed [14:22] Thanks! [14:23] henninge: apologizing for not finding anything wrong may be going a bit far :) [14:23] .... [14:24] yeah, let me see if I can find something wrong, then [14:24] uh-oh [14:27] jtv: the indentation of the parenthesis on line 319 and 332 looks strange ... but I may be wrong. [14:27] same on line 350 [14:27] jtv: there you go! ;) [14:27] Thank you, that's better. :) [14:28] The indentation looks a bit weird there because we rarely open a parenthesis on a line of its own. [14:28] In this case though I do think it makes sense. [14:28] yeah, I guess I was wrong, then ... [14:29] well, actually I wasn't as we agree about the strangeness. [14:29] I'm not sure there's any perfect answer. [14:29] I generally like what I think is GNU style, with opening and closing braces identically indented. === flacoste changed the topic of #launchpad-dev to: devel is release-critical until r13163 deployable | https://dev.launchpad.net/ | On call reviewer: henninge | Critical bugs:208 - 0:[######=_]:256 [14:38] gary_poster: you probably want to land your bug 792493 branch on devel once PQM gets out of RC-mode [14:38] <_mup_> Bug #792493: Creating a structural subscription for a team with a preferredemail makes a mute link that oopses < https://launchpad.net/bugs/792493 > [14:39] gary_poster: also, i downgraded the revision to deploy to 13163 since that's the one that include the merge, your other RC can be deploy nodowntime afterward [14:39] so it's not a blocker per se i think [14:39] It is unless we want to delay the unflagging for hours and have bugmail links broken. [14:40] We cannot turn the flag on by default without 13164. [14:40] flacoste, what wgrant said. My branch is not that important, but his is === flacoste changed the topic of #launchpad-dev to: devel is release-critical until r13164 deployable | https://dev.launchpad.net/ | On call reviewer: henninge | Critical bugs:208 - 0:[######=_]:256 [14:41] ok, makes sense [14:41] shouldn't be a big problem [14:41] cool [14:41] anybody took care of the conflicts yet? [14:42] I can prepare a branch if you want, but it's pretty trivial. [14:43] Since you can just take the files from devel. [14:43] yeah, no problem [14:43] There's only three. [14:44] flacoste: We'll be remerging db-stable tomorrow once devel reopens anyway. [14:44] So no need to reland it on devel. [14:45] yep [14:45] mrevell, mail sent (with two screenshots inline; hope that's not too annoying) [14:46] Thanks gary_poster, looking now. Not at all annoying :) [14:46] cool :-) [15:00] Does running launchpad impair the ability for my apache to server php? [15:03] nigelb: rocketfuel-setup installs apache2-mpm-worker, and PHP isn't threadsafe so it must be removed. But LP works fine with apache2-mpm-prefork instead of -worker, so you should be able to install libapache2-mod-php5 again. [15:03] (it will remove -worker and install -prefork) [15:03] wgrant: I tried that and it ended with an unsucessfull install, but its fine. I'll just use nginx :) [15:05] nigelb: What went wrong? [15:05] I've done it in the past. [15:10] Project windmill-devel build #175: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill-devel/175/ [15:14] wgrant: dpkg failures [15:24] nigelb: Huh. [15:41] jelmer: were you able to QA the bzr upgrade? [15:47] henninge, I see you saw I marked bug 410864 as related. I agree it looked like a dupe too... [15:47] <_mup_> Bug #410864: 'choose a source package' suggests undefined when search has too many results < https://launchpad.net/bugs/410864 > [15:48] henninge, but I thought I'd be cautious and leave it separate since the widget was used differently. [15:48] deryck: argh! [15:49] deryck: I just read the bug properly. It is not the same bug and it is not fixed. [15:49] Actually, I had wondered about what is described there while fixing the bug. [15:50] henninge, I walked through the steps in the bug on qastaging and had a nice list of packages to choose from. over 35 steps, IIRC. [15:51] 35 steps in the results picker, I mean [15:51] * henninge has to try this now === salgado is now known as salgado-lunch [16:01] deryck: :( [16:01] Why the frown? [16:01] deryck: qa-bad [16:01] ah sadness indeed. How is it bad? [16:02] deryck: It broke the check for picker with search boxes. [16:02] I don't get meaning of "the check for picker with search boxes" [16:02] hm [16:02] henninge, how is it broken? Sorry to be dumb. [16:03] I just got a result box with 220 batches. [16:03] deryck: https://bugs.qastaging.launchpad.net/ubuntu/+source/linux/+bug/687392 [16:03] <_mup_> Bug #687392: Kernel panic with 2.6.32-26 security upgrade < https://launchpad.net/bugs/687392 > [16:03] heh a ha! [16:04] deryck: edit "Linux" and enter "linux" into the search box. [16:04] I see it now. [16:04] only 220 pages! :) [16:05] deryck: Unfortunately I have to leave really soon and have no time to fix or rollback. [16:05] henninge, so depending on where we are in the qa process, i.e. if qa-ok revisions ahead of you, which is likely. I'd still leave it qa ok and do a follow on fix.... [16:06] henninge, it's a corner case that this many results will turn up normally. and ugly, big corner case. but at least the inital bug is fixed and the picker is usable... [16:06] if ugly. [16:06] oookaaay [16:07] henninge, so either constrain the widget width, or limit the number of pages we show. is anything beyond 40-50 pages useful? [16:07] deryck: the limit is 20 [16:07] deryck: I removed it for Robert's special case but unfortunately it leaked into other cases it seems. [16:08] henninge, right, but you could only display 20 and not limit on 20. [16:08] deryck: I filed two other bugs for a proper fix. [16:08] I think they are linked from my mp? [16:09] deryck: I will fix this tomorrow and maybe include a fix for bug 410864. [16:09] <_mup_> Bug #410864: 'choose a source package' suggests undefined when search has too many results < https://launchpad.net/bugs/410864 > [16:10] henninge, great, thanks. [16:10] though I'm still not clear why 410864 isn't fix since we just looked at 220 results on that page. ;) [16:10] but we can talk about it tomorrow. [16:15] I am 2 hours into my day. I am already burned. No doubt because I worked 3 days to see progress. [16:15] 1. We do not need a special JS for linting/evaluating. I can make seed do it [16:15] 2. I can run YUI tests without firefox, or any browser, I do not require a database or the web server. The test runner still needs xvfb, [16:17] jcsackett: do you have time to talk? [16:18] sinzui: sure, but one moment. i need to reboot. [16:20] flacoste: wgrant said we'd have to wait until staging gets updated as it has a importd we can use for testing [16:21] sinzui: back, calling you now. [16:22] jelmer: don't we have a bazaar.qastaging ? i'm sure we can test at least basic bzr functionality there [16:23] flacoste: the basic bzr functionality we can test there - and that works, but all the bugs associated with my branch require running of a importd with the new code [16:24] jelmer: staging is running 10647 and you require 10649 right? [16:27] flacoste: what branch are those revno's for? [16:28] jelmer: db-stable, that's what staging runs, i see that your stable landing was merged on db-stable at 10649 [16:28] (on another note, why are there 5 people with recipes that build lp:~launchpad-pqm/launchpad/stable) [16:29] flacoste: ah, yep [16:30] jelmer: recipe: i hav eno idea [16:30] people trying to autobuild launchpad .deb? [16:31] Oh dear. That's an impressive lack of clue [16:31] yet hilarious at the same time [16:31] I guess.. none of them merge in any packaging branches though, so that's doomed to fail [16:32] It's about as ridiculous as requesting subversion code imports from bazaar.launchpad.net, which people also seem to do from time to time [16:33] maxb: we should fix that by just letting them enter a URL and Doing The Right Thing [16:33] But, what is The Right Thing? [16:34] It's not even clear what they are hoping to achieve [16:34] maxb: In some cases I guess a mirror (if it's a bzr branch elsewhere), if they're trying to import from bazaar.launchpad.ent we should tell them to "bzr branch && hack && bzr push" [16:34] maxb: I think they're looking for the fork button [16:35] Could be [16:36] On a related note, we could use a "Do you really want to be doing this?" banner for people entering questions on Launchpad itself [16:37] Back on the code import issue, I think https://code.launchpad.net/+code-imports/+new is wrong to default to Subversion [16:37] It should default to nothing and force you to pick one [16:37]