[00:01] hah [00:01] 30ms query in all product traversals [00:01] with pillarname.alias_for IS NULL, when the alias_for index is partial on NOT NULL. === StevenK changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: StevenK | Firefighting: - | Critical bugtasks: 4*10^2 [00:34] * wgrant dies quietly. [00:40] lifeless: https://code.launchpad.net/~wgrant/launchpad/bug-932438/+merge/93109 would enjoy your perusal. [00:40] StevenK: Could you please review https://code.launchpad.net/~wgrant/launchpad/bug-932451/+merge/93111 and https://code.launchpad.net/~wgrant/launchpad/bug-932433/+merge/93110? [00:43] * wgrant headdesks repeatedly [00:43] goddammit [00:43] did nobody actually think when they were writing any of the queries on Product:=index [00:43] Half of them are unindexed. [00:43] So they only work at all because the tables only have 100000 rows. [00:44] Oh look, now the query is 0.1ms [00:45] wgrant: r=me * 2 [00:46] Thanks. [00:53] And another two missing indices. [00:54] That should be about 400ms off /unity now, I think. [00:55] wgrant: you forgot to request from stub as well [00:55] Blah, true. [00:55] If you hold off for a minute I'll have another two indices in there. [00:58] * StevenK peers at his ec2 run [00:58] It has dropped the entitlement table, but a method under IPerson is still trying to query it. [00:59] StevenK: Person merge will query anything that has foreign keys. [00:59] You'll need to drop the foreign keys before you move to todrop. [00:59] Only foreign keys to branch and person matter. [01:00] Oh, my DB patch is wrong [01:00] Well, it's right. [01:00] It just won't work. [01:01] We should possibly fix upgrade.py to drop todrop relations even when unreplicated, but I was never brave enough to do it. [01:04] wgrant: I need to ALTER TABLE person DROP CONSTRAINT entitlement_{approved_by,person,registrant}_fkey; ? [01:05] StevenK: ALTER TABLE entitlement, but roughly yes. [01:05] wgrant: But won't they get deleted if I just drop the entitlement table? [01:06] They will, but you can't drop the entitlement table. [01:06] You can only move it to todrop and then let upgrade.py have its way with it. [01:06] It will eventually drop in a replicated environment, but not AFAIK in an unreplicated one. [01:07] And we are possibly going to move the replicated drop to after service is restored. [01:07] Which means you'd have to drop the FKs early anyway. [01:08] * wgrant lunches. [01:08] wgrant: http://pastebin.ubuntu.com/842474/ [01:09] StevenK: Looks reasonable. Apply it locally and check that entitlement has no more FKs onto person or branch. [01:09] I didn't see any on branch, but I'll check [01:09] And then commit/push/re-toss at ec2 [01:09] There probably aren't any. [01:10] But those are the two tables that matter. [01:10] I was tempted to pg_dump launchpad_dev | grep entitlement | grep CONSTRAINT or some such [01:10] \d entitlement should do fine [01:11] huwshimi: got a minute for a css question? [01:11] wgrant: distribution, product and project too :-/ [01:12] StevenK: They don't matter. [01:12] Oh, they will get binned when the table does? [01:12] But the person FKs are thpecial? [01:12] They will all get binned when the table does. [01:12] Person and branch FKs are special because our code queries to find all of them. [01:12] On branch deletion and person merging. [01:13] Right [01:13] To check for references that need breaking or updating. [01:13] Oh, LFA also. [01:13] But there probably aren't any of those. === maxb_ is now known as maxb [02:19] wgrant: this needs a faq I think [02:19] wgrant: on the dbpatches pages [02:19] wgrant: its a vicious special case that folk don't touch often enough to have paged in [02:20] lifeless: Yeah [02:20] Probably. [02:21] But tests catch it, so it's not so bad. [02:24] wgrant: having a canned answer would avoid confusion. [02:24] wgrant: would you like to write one? [02:25] (I would like /someone/ to write one) [02:25] I two massive DB patches to finish today; maybe after that :) [02:27] lifeless: Is there a good reason we don't use HSTS? [02:28] I believe there are a couple of types of URLs (PRF downloads) that we force to HTTP for probably no good reason. [02:28] But HSTS is probably useful for performance as well as security. [02:32] get chrome to put it in their hardcoded list ? [02:33] wgrant: its never been discussed TTBOMK [02:33] back soon [02:36] lifeless: HSTS is a header [02:37] http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security [03:04] wgrant: I know [03:04] wgrant: (what in my answer suggested I didn't ?) [03:04] lifeless: You mentioned Chrome's hardcoded list. [03:05] yes [03:05] wgrant: http://www.chromium.org/sts [03:07] lifeless: Perhaps eventually. [03:07] But we should do the header first :) [03:08] that's a pretty random list of sites [03:08] And IE doesn't support it. This is my surprised face. [03:08] +download/blah is the only thing we don't currently server over HTTPS to browsers [03:08] And we'll have to start HTTPSing for some things soon. [03:09] (due to private projects) [03:09] +download/blah should be https [03:09] So hopefully https://rt.admin.canonical.com//Ticket/Display.html?id=30043 isn't an issue [03:09] any more [03:09] lifeless: You would damn well think so. [03:09] But Plone seems to be a bit screwed. [03:09] Or was in 2008. [03:09] so [03:10] this exemption should be backed up by logic in LP [03:10] +1 on nuking it, with a short list discussion to make sure noone is surprised [03:10] Great. [03:10] Then I shall deploy HSTS and X-Frame-Options and HttpOnly [03:11] do we generate http urls for +download ? [03:11] (the last of which requires a minor zope.session upgrade) [03:11] I believe so. [03:11] as long as you stop generating them the apache rule won't be in the way [03:11] (though that isn't a reason to preserve it) [03:11] Yep [03:14] return str(URI(url).replace(scheme='http')) [03:14] There's the guilty one. [03:15] Kill it [03:16] poolie: What are your not-4-year-old thoughts on https://bugs.launchpad.net/launchpad/+bug/174186? [03:16] <_mup_> Bug #174186: https redirects pose download problem

< https://launchpad.net/bugs/174186 > [03:25] StevenK: could you review https://code.launchpad.net/~wgrant/launchpad/remove-extra-privacy/+merge/93122? As discussed on the call this morning. [03:28] wgrant: The CTE flag never made it to flags.py? :-( [03:29] Nah, it was only meant to last a couple of days. [03:29] But I forgot to delete it. [03:30] first_product = self.factory.makeProduct(name='bunny') [03:30] I thought I saw something odd in the diff [03:30] Had it read it closer [03:30] wgrant: r=me [03:30] Thanks. [03:45] hi wgrant [03:46] wgrant, i think it's funny when things flip from fixreleased to invalid :) [03:46] it's not a practical issue for bzr atm afaik [03:46] i would leave it ~wontfix [03:47] poolie: It's really Fix Released, but the Great LP Project Merge let the Invalid malone task take over. [03:47] So it's currently fixed. [03:47] how is it fixed? [03:47] But I am going to unfix it unless someone brings up a very good reason to not. [03:48] Check the download links on https://launchpad.net/bzr/+download [03:48] They're the only internal HTTP links in Launchpad [03:48] wow [03:48] that's crazy [03:48] All because of Plone [03:49] I knew Plone was evil, this just confirms it [03:49] please do fix it, i think it's a bug, arguably a serious one, that those links are insecure [03:49] One would think so. [03:49] Thanks. [03:49] i do think it's nice if there is at least the option to get the final file over http [03:49] ie if the librarian speaks http if you ask for it on the final url [03:49] You can s/https/http/ in the librarian URL and it will still work. [03:49] If you really must get a compromised copy of the file. [03:50] yep [03:50] i think that's a decent accommodation to the specific case of broken clients or ridiculous firewalls [03:51] I might just make the change and then publicly shame anybody who complains that their stuff is broken. [03:52] public shaming isn't a terribly friendly strategy [03:52] Neither is downloading code over HTTP :) [03:53] the issue like this that does currently annoy me is that curl, by default, doesn't follow redirects [03:53] but, lp probably can't do anything about that [03:53] i guess if we wanted to help people like this [03:53] we could generate librarian urls directly in the page [03:53] and i'm not saying it's a priority [03:53] except for private context [03:53] *content* [03:53] right, put the final url [03:53] and then people can more obviously make the protocol change themselves [03:54] OTOH its a special case for pretty low return [03:54] curl should really follow redirects over HTTPS [03:54] i don't know why it has that default [03:54] also it just gives you an 0 byte file rather than erroring [03:55] oh well [04:03] poolie: (curious) have you filed a bug ? [04:03] There's an option to make it follow the redirect. [04:08] wallyworld: Did you notice you got r14800 ? [04:09] no [04:09] what's the significance? [04:09] wallyworld: Your MP fix is r14800 [04:09] lifeless, nup i assumed it was intentional [04:09] It's a 00 number! [04:10] They're special or something [04:10] oh, ok :-) [04:10] i feel much better knowing that [04:10] StevenK: +2 damage [04:11] * StevenK grumbles at the lack of QA [04:19] StevenK: https://code.launchpad.net/~wgrant/launchpad/bug-932518/+merge/93127 is as discussed above, +4/-118. But you've done a few of mine today, so feel free to ignore if you've had enough :) [04:20] And here I was figuring it was payback for yesterday. :-P [04:20] I only took like two of yours yesterday. [04:20] I was a bit surprised when you decided to throw one at wallyworld. [04:22] wgrant: I figured I had annoyed you enough. But, r=me [04:22] Thankyou sir. [04:23] StevenK: I might point out that all the bugs I've squashed today have been bugs that I also filed today :) [04:24] They're still squashed. :-P [04:25] wgrant: https://code.launchpad.net/~stevenk/launchpad/two-part-combobuild/+merge/93125 [04:26] Curses. [04:29] StevenK: It's not a problem any more that meta.js won't be in the minified output? [04:30] wgrant: No, we were using meta.js only, and the difference between them is only 4K [04:30] StevenK: Also, why do we want to do this? [04:31] Doesn't this mean prod will now minify twice? [04:34] wgrant: We want to do this for Rick's work of the tests using JS under build/js [04:34] And yes, for the short term [04:35] Ah, right. [04:36] r=me [04:36] wgrant: Thanks! [04:44] * StevenK wonders how to make visibility the third field [04:45] huwshimi: ping [04:45] wallyworld: Yo [04:45] huwshimi: i have a ccs question for you https://pastebin.canonical.com/60211/ [04:48] lifeless: Am I allowed to make code changes in db-devel as long as they're not necessary on production? [04:48] wallyworld: Is there a reason that description is in the then? [04:49] lifeless: I want to have tests for these triggers. [04:49] lifeless: Which probably means introducing new Storm classes etc. [04:49] huwshimi: so a user can click anywhere in the text to fire the link [04:50] huwshimi: i don't understand why the text-decoration: none is being ignored [04:51] wallyworld: It's probably to do with specificity and how the underline is applied to the a tag. You might be able to try ".yui3-ichoicelist a .choice-description:hover" (notice the "a" there). [04:51] I thought FormFields was a list. :-( [04:51] huwshimi: thanks, will give it a go now [04:52] Since I don't want to add it near the end [04:52] Well, at the end [04:54] wgrant: no [04:54] huwshimi: no go sadly. [04:54] wallyworld: Do you use chrome or firefox? [04:54] wgrant: thats the short answer; the long answer is that its really hard to be -completely- confident nothing will leak [04:54] huwshimi: ff [04:55] wallyworld: Hmm.. I wanted to check something, but I'm not sure how to do it in Firefox [04:55] wgrant: I suggest you do the tests in a branch, review it as a branch + prereq, and land separately [04:55] huwshimi: also bad in chrome [04:55] lifeless: k, thanks [04:55] just checked [04:55] wallyworld: Oh, yeah I just wanted to check something in Chrome's inspector [04:56] wallyworld: As in, if you inspect the span if the css rules are being crossed out [04:56] huwshimi: since it's the same in both, you can check in chrome [04:56] i'll have a look also [04:57] wallyworld: is this code only in your branch? [04:57] huwshimi: yeah [04:58] wallyworld: oh wait, so the color: green IS being applied to the span? [04:58] huwshimi: yes [04:58] wallyworld: Oh! [04:58] hence my confusion [04:59] wallyworld: Wait, so when you hover medium everything gets underlined but the span doesn't go green right? [05:00] huwshimi: the span goes green as expected BUT everything is underlined [05:00] and i don't want the text in the span underlined [05:00] so the color is being applied but not the decoration style [05:00] wallyworld: strange, I'd expect the green to only apply when you're hovering the span text [05:00] yes, sorry [05:01] it only applies when you hover [05:01] The browser/reset a:hover won't have a colour [05:01] So it won't override it [05:01] It *does* have a text-decoration [05:01] wallyworld: So what you need is this: ".yui3-ichoicelist a:hover .choice-description:hover {" [05:02] let me try that [05:02] wait [05:02] wallyworld: .yui3-ichoicelist a:hover .choice-description { [05:02] I left a :hover at the end [05:02] * StevenK feels utterly dirty. [05:02] + field = self.form_fields.__FormFields_seq__.pop() [05:02] + self.form_fields.__FormFields_seq__.insert(2, field) [05:03] huwshimi: sadly no. i'll keep trying [05:04] wallyworld: Can you push your branch somewhere and I'll have a quick try? [05:04] huwshimi: lp:~wallyworld/launchpad/choice-popup-descriptions-932424 [05:05] wallyworld: Cheers [05:05] huwshimi: you need to turn on ff disclosure.enhanced_choice_popup.enabled [05:05] wallyworld: OK, np [05:05] and run bin/combine-css [05:05] and make jsbuild [05:05] thanks in advance :-) [05:05] huwshimi: then, just goto any bug and click the bug status popup [05:06] or importance [05:21] wallyworld: So the problem is that the child element (the span) is doing what it's told. With the "a: hover span" it's not underlining the text when we hover the span just as we want it to. The problem is the span was never underlining the text, that's coming from the parent element, the and child elements can not override a parent's. [05:23] wallyworld: So what you'll have to do is move the "Medium" into another span. Set a:hover { text-decoration: none; } and then a:hover .medium-span { text-decoration: underline; } [05:23] wallyworld: Does that all make sense? [05:23] huwshimi: i'm digesting it [05:23] huwshimi: so a child element can't override a parent? seems quite limiting [05:24] wallyworld: Welcome to CSS [05:24] :) [05:24] it just seems broken [05:24] must be a reason for it [05:24] huwshimi: thanks for looking, really appreciate it [05:24] i'll try it out [05:24] wallyworld: No problems. Let me know how you go [05:25] huwshimi: will do. may have to go and get the kid from school before i get it going [05:25] wallyworld: Got one sec? [05:25] StevenK: yes [05:25] gone [05:26] want another? [05:26] wallyworld: Y.one('#field.subscriptionpolicy'); [05:26] wallyworld: Is that by class or id? [05:26] won't work [05:26] # is ID [05:26] by id [05:26] But also by class [05:26] id field, class subscriptionpolicy [05:26] but Y.one doesn't like ids with '.' [05:26] The linked bug was marked as fixed in 3.0.0 [05:27] StevenK: Y.one("[name='field.subscriptionpolicy']") [05:27] will work [05:27] assuming the element comes from a lp form [05:27] where zope sets the name [05:28] otherwise Y.DOM.byID() will work [05:28] or something like that [05:37] lp.buildmaster.tests.test_builder.TestSlave.* just failed for me on ec2 :-/ [05:37] * StevenK stabs them [05:38] The librarian probably stole its port. [05:38] lp-land and move on? [05:38] Yup === almaisan-away is now known as al-maisan [08:47] ood morning [09:40] stub: That milestone thing seems pretty odd. [09:40] Given that the primary parent of a milestone is a series. [09:44] stub: It's also a small extremely read-heavy table, queried in some places where we don't actually have the series object, just the ID. [09:44] So it will be some pretty awkward refactoring to avoid a harmless index, and use an index on a deprecated column instead. [09:45] Ok. If we need the index to avoid a join with distroseries or productseries [09:45] I've found one place where it is cleaner to query on product. [09:45] And productseries isn't necessary at all. [09:46] But many others really want to deal in series :/ [09:46] Yup. So no real harm adding them. [09:47] Did you see my comment about productreleasefile? [09:47] Did you do timings on the productreleasefile index btw? [09:47] * stub refreshes [09:47] On its creation, or the queries? [09:47] On DF the example query I used goes from 60ms to 0.5ms [09:47] I can pull it up from history if you want. [09:48] oh, brain fade. I'm too used to the id columns being the first column [09:49] Heh, yeah, that is a bit odd. [09:49] Did productrelease used to be the primary key? Can't think why it would be out of order like that unless it was added later. [09:49] I assume it was (productrelease, libraryfile) [09:49] But surely not, since SQLObject doesn';t support that. [09:49] So maybe it was just for storing a single tarball per release? :/ [09:49] It might have if you tried hard enough [09:50] Not sure when the table arrived. Doesn't matter anyway. [09:51] r=stub [09:51] Thanks. [09:51] It would be nice if we could globally profile planning overhead :/ [09:52] stub: Can you apply those live, please? [09:53] Or should I land first? [09:53] I've tested them live on DF. [09:53] I'll apply them now [09:54] Thanks. [10:03] wgrant: Done [10:03] stub: Thanks! [10:03] * wgrant tries and lands. === matsubara-afk is now known as matsubara === al-maisan is now known as almaisan-away [11:27] morning [11:32] thanks for the combo build updates StevenK, will try landing again this morning woot! [11:34] Hehe === Ursinha_ is now known as Guest37786 === Guest37786 is now known as Ursula === almaisan-away is now known as al-maisan [14:30] adeuring, abentley, rick_h -- https://plus.google.com/hangouts/extras/talk.google.com/orange-standup [14:54] abentley, adeuring -- it doesn't kill the hangout when I leave, does it? [14:55] deryck: works fine [14:56] ok, cool [15:02] Hello. The Commercial Engineering team would like to increase the default size of a PPA owned by ~oem-archive upon creation. I do not believe this is something we can currently do via the API. If that's true, is there a way to increase the default on a per-team basis with a little magic on your end? [15:03] it would be an easy patch for you guys to do [15:03] (to set it via the API) [15:05] bigjools, okay, that is what I needed to know [15:05] one other thing... [15:06] bigjools, the understanding that I have which is based on the understanding of my boss is that we can jack the default up to 1TB with the understanding we'll never actually consume that much space? Does this match your own understanding? [15:06] timrc: echan for this === abentley changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: abentley | Firefighting: - | Critical bugtasks: 4*10^2 === al-maisan is now known as almaisan-away [16:00] rick_h, give me 2 minutes and I'll join you on hangout. [16:01] deryck: k [16:05] rick_h, https://plus.google.com/hangouts/extras/talk.google.com/go-for-deryck [16:20] is anybody else getting xmlrpc errors related to the uniqueness of owner_name, when pushing to qastging? === salgado is now known as salgado-lunch [16:25] jelmer, I am seeing null value in column "owner_name" violates not-null constraint when pushing a new branch [16:26] sinzui: thanks, so it's not just me [16:34] sinzui: are we going for a JS/mustachy approach on the +sharing, or ... ? [16:36] jcsackett, Yes. [16:36] sinzui: cool. [16:36] i had *assumed* so, but was suddenly wondering. :-P [16:37] jcsackett, The search form and filters stumped the punters. We will do some paper mockups to revise what and how we display them. Assume the table is good to implement for stakeholders to try in the next two weeks [16:38] sinzui: dig. the side portlet summary bit too, i'm guessing? (seems *very* uncontroversial). [16:38] They are [16:38] righton. [16:39] We do need to update the text about sharing Some. This is really an audit and retraction state, we do not allow users to grant it and we do not explain who someone might accomplish sharing Some. Dan and I will work on that [16:42] bigjools: hai [16:42] lifeless: yellow - needed to talk to you as it happens [16:42] bigjools: we should talk a little about the ppa admin / commercial admin thing [16:43] now is not a great time [16:43] sure [16:43] what did you want tto ttalk aabout ? [16:44] I want to poke you to make a testtools release and push it to debian so I can sync it to precise [16:44] jono fixed a nasty bug [16:44] yes [16:44] then did a release [16:44] it had a regression [16:44] another release is needed, I'm not sure if he has done that yet [16:44] arses [16:44] jml: ^ oh hai [16:45] what's up? [16:46] jml: backscroll [16:46] oh right testtools [16:46] haven't any feedback on my subunit branch [16:46] wanted that before I released, since the regression is changing a private API that subunit relied on [16:46] I can do something about that [16:47] jml: it conflicts [16:47] lifeless: it didn't when I submitted it, and I'm pretty busy right this second. [16:48] jml: I haven't changed trunk since [16:48] jml: given your other branch which duplicated stuff done in trunk a couple weeks back, I'm fairly sure you worked off of a stale base of some sort [16:48] lifeless: ok whatever, it *did* conflict when I submitted and I'm pretty busy right this second. [16:48] so, let me see if I can figure out what it is doing [16:51] reviewed [16:51] lifeless: thank you. [16:52] lifeless: I'm unlikely to get to that until tomorrow morning UK time, but will try to do so then. [16:56] danhg, wallyworld is landing a change that will allow Lp to show the definition of an enum: http://people.canonical.com/~ianb/enhanced-choice-picker.png [16:56] danhg, I think we need to rewrite some bug definitions before putting the feature into beta === salgado-lunch is now known as salgado [17:11] woot! combo loader tests passed yay [17:15] rick_h: nice! [17:16] * rick_h sees a light in the tunnel...now to determine if it's aimed at him [17:24] rick_h, awesome [17:30] any losas around want to help a brother out with another merged-account-openid-confused issue? https://answers.launchpad.net/launchpad/+question/187825 [17:31] mtaylor: only one at the moment (me) and I'm in a meeting I'm afraid - can you assign it to ~canonical-losas and someone will get to it at some stage [17:32] mthaddon: I surely will! thanks! [17:33] thx [17:33] mthaddon: it won't let me assign - is subscribe someone else good enough? [17:40] mtaylor: I've assigned it to be sure [18:00] bwuhahaha, the quad-ec2 land. === deryck is now known as deryck[lunch] === deryck[lunch] is now known as deryck [20:22] flacoste: got a minute ? [20:23] lifeless: sure [20:25] evening [20:25] morning [20:29] thumper: hey [20:31] is there a way to get a history of all previously merged branches from launchpadlib? [20:37] deryck: hey, do you ahve time for a quick chat this avo ? [20:41] lifeless, I don't actually. and was trying to keep my tomorrow afternoon open for hacking, too. just trying to finish my current branch. [20:41] lifeless, should we try to get in something just as you come online tomorrow? [20:41] lets do [20:42] will be a short call, I promise [20:42] ok, sounds good. [20:42] thanks! [21:07] czajkowski: hey [21:08] lifeless: evening === matsubara is now known as matsubara-afk [21:08] oh, I was going to talk about trivial vs nontrival when I realised I had misread the bug. [21:08] czajkowski: also good evening ;) [21:09] lifeless: mind If I ask you a q re a bug while I'm here [21:09] of course not [21:09] lifeless: thanks re : https://bugs.launchpad.net/launchpad/+bug/931131 [21:09] <_mup_> Bug #931131: recipes attempt to build packages with version older than previous build < https://launchpad.net/bugs/931131 > [21:10] it's been confirmed by the janitor, but after you commented on it, wasn't sure if it should be marked triaged? [21:10] it hasn't been triaged [21:10] (not the importance is undecided still) [21:11] I'll triage it now; yes you are right the status [and importance] needed setting [21:12] ok, just didnt want to change it today without askin so I can know in future [21:12] czajkowski: don't stress, you *will* make mistakes, and they will be easy enough to fix :) [21:12] czajkowski: you've seen https://dev.launchpad.net/BugTriage right ? [21:12] czajkowski: I have to pop out for a bit; have a good evening. [21:13] lifeless: I did and will keep it open during the day, but was going through stuff with mat today and just wanted to check [21:13] thanks === abentley changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 4*10^2 [21:58] jelmer: Hi [22:02] wgrant: jcsackett aloha [22:03] Evening czajkowski. [22:03] aloha, czajkowski. [22:03] jcsackett: hi [22:04] folks having a good day/end of day ? [22:06] passably good. :-) [22:09] lifeless: Do you know what's going on with the two branch scanner revs? [22:09] One is bad, but not rolled back AFAICT. [22:10] I have not heard [22:10] jelmer: ^ ohai [22:10] hi wgrant, lifeless [22:10] I'm in the process of rolling them both back [22:10] the other one is probably fine but I can't really QA one without the other [22:13] jelmer: Any reason this wasn't reverted a few hours back? It's just missed another buildbot run. [22:16] nn folks [22:17] wgrant: I didn't have the time to (it's well past EOD here) [22:17] k [22:18] In general, rollbacks are the most critical thing that can be done. If you don't have time, please poke someone else to do it. [22:19] ok [22:20] + # We'd like visibility near the top. Eyes closed, please. [22:20] + field = self.form_fields.__FormFields_seq__.pop() [22:20] + self.form_fields.__FormFields_seq__.insert(2, field) [22:24] jelmer: thanks. And for context - LP has been blocked for 2 days now; our goal is multiple deploys *per day*, so this is a massive impediment [22:26] lifeless: Sorry. I didn't mean to impede. It's been a while since I've landed something and landings seem to be happening a lot faster now. === salgado is now known as salgado-afk [22:28] jelmer: tis ok; I'm explaining why you're getting nagged so much :) [22:32] StevenK, self.form_fields = self.form_fields.select(['name', 'visibility']) [22:35] StevenK, http://pastebin.ubuntu.com/843663/ show a reselection for field to omit/change the order of setup fields [22:36] jelmer: Thanks. [22:36] * wgrant murders buildbot. [23:02] sinzui: https://code.launchpad.net/~stevenk/launchpad/better-name-field/+merge/93317 [23:02] thank you [23:09] wallyworld_, I think these two bugs relate to the errors users see when creating teams because the form is governed by invariant rules: bug #463563 bug #604289 [23:09] <_mup_> Bug #463563: Create a new team UI has optional renewal period, then returns an error when not supplied < https://launchpad.net/bugs/463563 > [23:09] <_mup_> Bug #604289: on open teams / mailing lists 'renewal' doesn't make much sense