[00:00] I'm on the way [00:02] i'll do the hg branch then [00:02] Excellent. I don't want to kill it, I just want to see it dead. [00:03] wgrant: Shall I commit a change to dbpatches -- 36-1 for me for DROP COLUMN private_bugs and 36-2 for you to kill BVP? [00:04] Hmm, you already have one, 26-[01] [00:04] wgrant: In that case, can I co-opt 26-2 to DROP COLUMN private_bugs ? [00:05] Sigh, I should learn to read at some point. [00:09] StevenK: You should probably use 26-5 or so [00:09] Yeah, I just picked 26-5 [00:14] Oh right, forgot about hg [00:25] are private bps in a useful state yet? [00:25] They break everything [00:25] But they are private, I believe [00:25] heh [00:26] do they make listing views 403 and such? [00:26] Right, that sort of thing [00:26] are they being worked on by anyone? [00:26] The most egregious regressions were fixed a few days after they were switched on on production [00:26] But they're still working on the others [00:27] They should be fixed soon [00:27] ok cool [00:27] are they feature flagged ? [00:28] To beta-testers, I think [00:28] Some would say that the beta test is slightly premature [00:29] ah, i think i need to acquire a commercial subscription to do anything [00:29] Right [00:30] A project needs a commercial sub to enable proprietary features. [00:30] And there's no security- or user-related private blueprints [00:30] do you know if linaro projects can get a commercial sub by asking? [00:30] I believe that's still the case. [00:31] cool [00:31] If you add Other/Proprietary to your licenses you'll get a 30 day sub, and then you can ask us to extend it [00:33] StevenK: I've put a few minor comments on the MP [00:33] So has Curtis [00:34] Oh [00:34] So he has [00:34] wgrant: Damn it, I thought I had renamed that Mixin :-( [00:35] * StevenK laughs at your 'orly' [00:36] wgrant: i guess i'll wait until things have settled down a bit, but thanks [00:37] mwhudson: Sounds reasonable. [00:41] wgrant: So I guess we could make use of getDefaultBugInformationType if the target is an IProduct and override to PRIVATESECURITY if security_related [00:42] StevenK: Except that BugSharingPolicy.PROPRIETARY doesn't permit PRIVATESECURITY [00:42] StevenK: This should perhaps use similar rules to the API's BugSet.createBug' [00:42] (which will likely reveal bugs in that method) [00:43] wgrant: So we already set information_type using convert_to_information_type() just before createBug [00:44] And in fact, it's always created on a product [00:46] wgrant: Perhaps we should do what you suggest -- assert self.product.bug_sharing_policy == BugSharingPolicy.PUBLIC [00:47] That's certainly safest for now, and probably not immensely limiting [00:48] Huh [00:48] Project:+branches shows BVPs publicly [00:48] Didn't realise that [00:48] (Project, not Product) [00:58] wgrant: So the only thing I haven't done is re-add the block that starts with 465 - # Security bugs must be created private, so set it correctly. [00:59] wgrant: Why should we run it all the time? We create the bug with information_type specified. [00:59] Do we? [00:59] Then why is that block there :/ [01:01] Maybe all that's missing is if security_related: private = True and we're done [01:01] But people can import bugs as PUBLICSECURITY, it doesn't matter much [01:08] wgrant: Have another prod at that MP? [01:23] StevenK: Looking [01:24] StevenK: Mysterious [01:24] wgrant: What is? [01:24] I ran format-imports over the tree just two weeks ago [01:24] Perhaps there were comments in the way [01:24] Ah [01:24] Obsolete cElementTree crap [01:24] Can you remove that [01:24] ? [01:24] bugimport resists format-imports due to that bloody try [01:25] wgrant: Sure, I just didn't know which one is the obsolete one [01:25] THe one that doesn't work any more :) [01:25] cElementTree is long-deprecated IIRC [01:26] >>> import xml.etree.cElementTree [01:26] >>> import cElementTree [01:26] Traceback (most recent call last): [01:26] Yeah, already done [01:33] wgrant: The MP has updated. [01:43] StevenK: You still seem to have that XXX'd block in createBug [01:43] 395 - if (IProduct.providedBy(params.target) and params.target.private_bugs [01:43] 396 + if (IProduct.providedBy(params.target) [01:43] Oh, that's gone [01:43] Hm [01:44] Ahh, in an earlier rev while I was writing my first review [01:44] Sneaky [01:44] Yeah, because Curtis pointed it out [01:44] r=me [01:45] * StevenK tosses it at ec2 test to see how much hate mail he gets [02:16] death-to-private_bugs => devel [FAILED] (up for 0:31:04) i-35592f48 [02:16] Hahah, that didn't take long [02:18] from lp.bugs.scripts.bugimport import ET [02:18] * StevenK facepalms [02:18] That's impressive [02:18] Or is that a test? [02:19] It's in a test [03:10] bollocks. my ec2 credentials have become invalid :-( [03:10] Oh? [03:10] ec2 land spits back a 401 [03:10] Paste? [03:11] let me retry [03:11] boto.exception.EC2ResponseError: EC2ResponseError: 401 Unauthorized [03:11] [03:11] AuthFailureAWS was not able to validate the provided access credentials3b25f70c-bc80-4470-b867-e24ad24f42da [03:11] Wow [03:12] wallyworld_: Can you log into AWS at aws.amazon.com ? [03:12] trying now [03:14] yep, everything ok [03:14] maybe i'll have to reset my credentials [03:15] i recently updated lp-dev-utils and it started happening after that, probably a coincidence [03:15] wallyworld_: So while logged in, compare ~/.ec2/aws_* with what's on AWS. [03:17] StevenK: you mean the Key/Pair link on aws? [03:18] wallyworld_: I have .ec2/aws_id and .ec2/aws_user [03:18] yes, me too [03:19] the only security setting i can see on the aws site is the Key Pair link [03:19] wallyworld_: And no, these are your details [03:19] While logged into your AWS account, find the "Access Credentials" link (via "Account" -> "Security Credentials". [03:19] On the page, you'll see "Access Key Id:" and "Secret Access Key:". Make a ~/.ec2 directory in your dev box with a file called aws_id. In the first line, put your access key id. In the second line, put your secret access key id. [03:21] StevenK: they both match [03:21] wallyworld_: Then try it again? [03:21] without having to edit anything [03:21] i've tried several times [03:21] same error [03:22] maybe i just need to create new credentials [03:22] i've paid my bills i'm sure [03:22] Does your account have access to EC2? [03:23] I successfully started an ec2 test run using lp-dev-utils r128 this morning [03:25] it let me launch an instance from the web interface [03:25] which shows up in ElasticFox [03:25] wallyworld_: bzr revno of lp-dev-utils? [03:26] 113 [03:27] wallyworld_: Maybe you should update that? [03:27] just did, i'm on the latest rev [03:27] i updated earlier too just to be sure [03:27] Then how am I on r128? [03:28] hmmm. [03:28] "Tree is up to date at revision 113 of branch bzr+ssh://bazaar.launchpad.net/+branch/lp-dev-utils " [03:28] i'll try grabing it again [03:28] I just went backwards too [03:29] ec2 ls still works for me [03:29] sigh, it hates me [03:30] Hmmmm, before I updated I had a bunch of revs from lifeless [03:30] Which I suspect were his PPR changes [03:30] i just checked out again and got rev 113 as tip [03:31] Yeah, Robert's stuff was merged in as r111 by Curtis [03:31] StevenK: the traceback shows system packages implicated [03:31] perhaps i've hit a quantal bug [03:32] File "/home/ian/projects/lp-dev-utils/ec2test/credentials.py", line 87, in connect [03:32] aws_secret_access_key=self.secret) [03:32] File "/usr/lib/python2.7/dist-packages/boto/ec2/__init__.py", line 55, in connect_to_region [03:32] for region in regions(**kw_params): [03:32] File "/usr/lib/python2.7/dist-packages/boto/ec2/__init__.py", line 39, in regions [03:32] return c.get_all_regions() [03:32] File "/usr/lib/python2.7/dist-packages/boto/ec2/connection.py", line 2421, in get_all_regions [03:32] [('item', RegionInfo)], verb='POST') [03:32] File "/usr/lib/python2.7/dist-packages/boto/connection.py", line 896, in get_list [03:32] raise self.ResponseError(response.status, response.reason, body) [03:32] boto.exception.EC2ResponseError: EC2ResponseError: 401 Unauthorized [03:32] [03:32] AuthFailureAWS was not able to validate the provided access credentialsf8efcb7a-afb9-45b3-98b0-75d18ee945f7 [03:32] * StevenK stabs wallyworld_ [03:32] ouch [03:33] We have this thing, it's a called a pastebin. Maybe you've heard of it? [03:33] it was only a few lines [03:33] sorry [03:33] 13 lines is a few? [03:33] less than 14 :-) [03:33] fsvo i guess [03:33] * StevenK stabs wallyworld_ again [03:34] ouch [03:34] wallyworld_: You may be right, though. My desktop is still precise [03:34] yeah, let me see if i can rollback those packages [03:38] StevenK: sadly, only the quantal version of python-boto is listed as being valid [03:39] wallyworld_: https://launchpad.net/ubuntu/+source/python-boto [03:39] Download the 2.2.0 version for precise [03:40] thanks, will try that [03:41] wgrant: I can't even force a team that owns a product to private using rSP? :-( [03:43] StevenK: bollocks. still no go. i must have neglected to sacrifice something to the gods [03:44] With the same traceback? [03:45] yeah, more or less [03:45] to the naked eye [03:46] Your eye should put some clothes on [03:46] perhaps [03:46] but i feel so comfortable without [03:47] * StevenK installs orca and scratches his own eyes out [03:47] wallyworld_: So I think you should work out where ec2 is loading your credidentals from [03:48] yeah, i'll do some digging. thanks for the input [03:48] let me know how orca goes for you :-) [03:48] Haha [03:48] there are some launchpad issues with it could could help fix [03:49] wallyworld_: At my last job, my manager was vision impaired. I could never work out how he could hear his screen reader nattering in his ear at 90wpm while having a conversation on the phone [03:50] yeah. i guess it takes practice [03:50] i can't understand how anyone can use a computer with just a screen reader to reply on [03:50] rely [03:50] wallyworld_: You should talk to TheMuso some time. [03:51] would be an insight for sure [03:51] wallyworld_: He's the one who filed the accordian widget doesn't love screen readers bug [03:52] there are others too for bug subscriptions i think? [03:52] I think that's the only one directly related to screen readers [03:52] ICBW [03:53] wallyworld_: Have you heard of Keith Packard? [03:54] no [03:54] wallyworld_: Works on X, and has been since the early 80s [03:54] vision impaired? [03:54] No, just glasses. But I'm getting to that [03:54] * wallyworld_ needs to learn patience [03:55] wallyworld_: He was giving a talk a few years on compositing to group of vision impaired people -- he found it a little confronting talking about GL transforms to a group of people who all had laptops, and half of them had no screens at all, since their user had no need for it at all. [03:56] i can imagine. we do take a lot for granted having decent eye sight [03:57] wgrant: So I can create a private team, but then that team can't own a product. Or I can create a public team and have it own a product, but then I can't force that team to be private. [03:58] StevenK: What are you trying to do and why? [03:58] Also, why can't you? [03:58] wgrant: https://bugs.launchpad.net/launchpad/+bug/1031751/comments/3 [03:58] We have private teams that own projects [03:58] <_mup_> Bug #1031751: KeyError: 'primary_vars' raised setting branch for a project < https://launchpad.net/bugs/1031751 > [03:59] In [13]: removeSecurityProxy(team).visibility = PersonVisibility.PRIVATE [03:59] ImmutableVisibilityError: This team cannot be converted to Private since it is referenced by a product and an accesspolicygrant. [03:59] I'm not sure that the project owner actually matters [04:00] Isn't it the team that you select on the form? [04:00] OH. I just need to be a member of it? [04:00] Any participant will do [04:03] * wgrant is still forcing a terrible weightloss regime on 2000 lines of test_branchnamespace [04:05] wgrant the Drill Master? [04:13] StevenK: found it. something has set some EC2 environment variables, which overrode my credentials [04:13] Haha [04:13] i have no idea whta/when/why [04:15] BLEH [04:16] ComponentLookupError: ((, ), , u'') [04:16] :-( [04:16] StevenK: Are you in the right layer? [04:17] wgrant: I'm in 'make iharness', so what's a layer [04:17] Ah [04:17] That should be fine [04:17] Except it isn't [04:17] Now now [04:17] You know how I feel about "facts" [04:18] wgrant: Ah. You say it should be fine, so it is? [04:18] wgrant: http://pastebin.ubuntu.com/1266897/ [04:19] StevenK: What have you changed? [04:20] wgrant: It's current devel with me creating two teams, a product, a series and then calling the view [04:20] Do you get the same exception in a test? [04:21] Last time I wrote this as a test, you told me it was pointless :-) [04:21] So I was trying to avoid that [04:21] Ah [04:21] You could try the Web UI. [04:23] ah. broken build. will do test fix [04:26] PrivatePersonLinkageError: Cannot link person (name=team-name-100005, visibility=PRIVATE) to (name=None)
[04:27] So the owner really can't be private [04:27] The owner of the codeimport isn't currently permitted to be, no [04:27] The owner of a branch is fine [04:28] The owner field is only enabled on ProductSeries:+setbranch if you say it's an import [04:28] So I guess it's validation time [04:28] Owner should be on +setbranch if it's an import [04:28] Isn't it? [04:29] Yes, and that's exactly what you just said [04:29] I can't read [04:29] Haha [04:29] So, time for a test [04:53] * StevenK stabs doctests [05:07] wallyworld_, wgrant: https://code.launchpad.net/~stevenk/launchpad/no-private-registrant-setbranch-redux/+merge/128415 [05:18] wgrant: How goes test_branchnamespace's radical diet? [05:32] Nearly there [05:33] Curtis is a tease. He commented on my MP, but didn't review it. [06:11] StevenK: sorry, was doing school pickup and buying coffee, i'll do your mp now [06:15] r=me [06:16] wallyworld_: Thanks [06:17] np. i fell better now i've had coffee [06:17] feel even [06:18] wallyworld_: You were going through withdrawl symptoms? [06:19] Did you phone up bigjools and beg him for a hit? [06:19] yes, and i had totally run out so it would have been unbearable tomorrow morning [06:19] no, not that desperate [06:19] yet [06:19] wallyworld_: that's condition double red [06:19] StevenK: bigjools and i are out of coffee sync sadly [06:20] he ran out last week while i still had some [06:20] wallyworld_: There's this thing, perhaps you've heard of it -- 'forward planning' ? [06:20] we need to sync our cycles [06:20] maybe we need to sniff each other's armpits [06:20] O_o [06:21] bigjools: i got that expensive stuff. hope it's good [06:21] wallyworld_: it's bloody great. Did you not try any when there? [06:21] didn't have time. got a take away which was ok but not spectacular [06:45] wallyworld_: Hmm [06:45] ? [06:46] Ah, bug #1052639 [06:47] <_mup_> Bug #1052639: Cannot change the information type of a branch when I unshare with the owner < https://launchpad.net/bugs/1052639 > [06:47] Was looking for the rationale for the extra check in ProductNamespace.getAllowedInformationTypes [06:47] Since it means that if the user has proprietary privileges, they can change the owner to any of their teams [06:47] Which possibly means that we want to dump the team restriction entirely [06:47] Thoughs? [06:48] eg. I was able to make https://code.qastaging.launchpad.net/~auditor-team/lp-production-crontabs/grackle2 [06:48] auditor-team has no privileges in lp-production-crontabs [06:48] not sure. i'll have to reread the code to get some context again [06:48] Until that fix, you could only change the branch owner to a team with privileges. [06:49] Which is a restriction we kept from the old BVP days, but we possibly just want to throw out now [06:50] so you can change the owner to anyone? [06:51] i guess if it's easy enough to correct mistakes and the principals fit with the goals for disclosure [06:51] then why not [06:51] maybe discuss tomorrow [07:11] wallyworld_: You didn't mark r16110 as a rollback of 16109 [07:11] ah bollocks. sorry [07:12] 56 revisions waiting. WCPGW [07:12] oh ye of little faith [07:12] wgrant, wallyworld_: I've marked the bug attached to r16109 as qa-ok just based on the fact it was rolled back in the next rev. [07:12] I imagine UK webops will be tied up for a while [07:12] StevenK: Yep [07:13] thanks, sorry [07:13] * StevenK peers at qastaging-update.log [07:16] 33 files changed, 105 insertions(+), 2741 deletions(-) [07:16] I think that's about it [07:17] Holy crap [07:19] StevenK: Does he beat your maximum deletions in one MP record? :) [07:19] Not sure [07:20] We need an app for that. [07:20] On that note. [07:20] I just realized, I have an incomplete MP. [07:20] Sigh. I wish I had time to finish it up. [07:21] steven@undermined:~/launchpad/lp-branches/devel% bzr di -c 12253 | diffstat -s [07:21] 19 files changed, 1789 insertions(+), 2767 deletions(-) [07:21] So, no. [07:23] Hah. [07:24] nigelb: [r=jelmer, henninge, gmb, allenap, edwin-grubbs, deryck][ui=none][bug=384220][no-qa] Take a bunch of Soyuz doctests, burn them in a large fire, and replace them with unit tests. [07:25] hahahahaha [07:28] * StevenK waits for the qa-tagger [07:29] Finished my qa before it ran === jelmer is now known as Guest86701 === mpt_ is now known as mpt [11:37] morning [11:39] rick_h_: ello [11:56] rick_h_: you not off today ? [11:57] czajkowski: I've got to try to finish this branch for private projects alpha, had tests/buildbot fail over hte weekend :( [11:58] but plan on running away once I get it working === benji changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: benji | Firefighting: - | Critical bugs: ~300 [12:00] rick_h_: any idea when https://bugs.launchpad.net/launchpad/+bug/1062207 will get looked at ? [12:00] <_mup_> Bug #1062207: Unable to raise blueprint < https://launchpad.net/bugs/1062207 > [12:00] rick_h_: Ah, since you're here... I reverted the product launchpad.View stuff, as it broke production [12:00] Just in case it's relevant to what you're doing here on your day not-so-off [12:00] czajkowski: tomorrow. abel knew what was up there. [12:01] wgrant: lanuchpad.View stuff? /me tries to jumpstart the brain [12:01] rick_h_: You guys restricted most of IProduct's attributes behind the launchpad.View permission last week [12:01] grand [12:01] wgrant: ah ok [12:02] If you current branch relies on private projects being private, it won't work :) [12:02] But otherwise you should be unaffected [12:02] hah, well we were supposed to be getting to alpha with it so I wonder if this blows that up [12:02] I'm hitting a different conflict I think [12:03] somewhere _information_tpe got turned into a db column information_type and I lost my getting/setter @property [12:03] but that's in the product model [12:03] There's still another month at least of work before you can think about having a single private project [12:03] On prod [12:03] I'm not sure what alpha entails, though [12:04] right, but deryck is supposed to be here today for a bit to flip the bits on enabling the alpha which lets users register a non-public project and we can check things out. [12:04] rick_h_: I probably reverted that infotmation_type bit [12:04] rick_h_: Um, no [12:04] Nobody is going to be registering any non-public projects for some weeks :) [12:04] Even if I hadn't reverted the code today [12:05] No code knows how to handle them [12:05] And it will make pages all across Launchpad 403 [12:05] heh [12:05] 10 bugs that Curtis filed over the weekend will immediately become critical regressions [12:05] And I'll be able to file another 20 or so [12:05] well, what I get for going on vacation and coming back just in time to pick up the alpha going boom :) [12:06] ok, well I'll still try to figure out how to fix this change up on my branches so they can land up and go from there. thanks for the heads up [12:06] Right, sounds like a good plan [12:06] I'll make sure to catch deryck when he comes online and get it sorted out [12:06] Turning on private projects on production today... not such a good plan! [12:06] oh boooo :P [12:07] Think of the blueprint 403 regressions, except on basically every page on Launchpae [12:07] d [12:07] That's what private projects on production today will do [12:08] ok, I knew we had an issue with the project listing page and abentley was working on updating the query, but I'm not up on the rest there [12:08] Entering an un-QAed restricted alpha is OK for normal things, but not for denying access to artifacts that leak to just about every single page of the application [12:08] It just takes one person to be even slightly adventurous and dozens of people can no longer do their work [12:09] Because pages they need are 403ing [12:09] gotcha [12:11] speaking of hte alpha bossman [12:11] yeah, what's this bad news? [12:12] deryck: so wgrant was telling me he had to do some reverting for us with launchpad.View because it broke production [12:12] and my branches didn't land over the weekend due to a test fail and buildbot breakage. [12:13] Right, various pages were 403ing after deploying r16090 (IProduct launchpad.View stuff), mostly due to deactivated projects showing up and no longer being accessible [12:13] but wgrant says that enabling the alpha right now would break a ton of stuff. He says curtis filed a bunch of bugs over the weekend [12:13] I'm still catching up on weekend stuff atm, but wanted to make sure you were caught up deryck [12:13] I reverted it so we could deploy the other 50 waiting revisions to production [12:13] More than 50 [12:13] What are the alpha plans? [12:13] wgrant, thanks, that makes sense defintely. [12:14] I need to look at sinzui's bugs to see what his concerns are. [12:14] deryck: What's the next alpha step? [12:15] wgrant, I'm sorry, I don't follow what you're asking. What do we need to do to get to alpha? Or what will the alpha provide? [12:16] Well, what's the general timeline for turning this stuff on? [12:17] wgrant, I had hope to get a deploy around late morning, early afternoon. I have a few test fixes to go for my last branch. [12:17] wgrant: doh yea so the revert changed back the model that my branch was based off of [12:17] deryck: So people creating private projects this week? [12:17] wgrant, but if the security adapter stuff is reverted, there's no point. [12:18] wgrant, yes, but only a small group. I will create an alpha team, and only add those who request it. [12:18] rick_h_: That bit can possibly be cheaply relanded. I just reverted the whole revision rather than weeding out the problematic bits (of which there are a lot) [12:18] deryck: I'm not sure that's such a good idea. [12:18] deryck: LP doesn't know how to filter private projects yet [12:18] wgrant: yea, it's abel's beast hitting a lot of stuff so I think at this point I'll wait until tomorrow and work with abel to catch up. [12:18] So if one of those projects shows up anywhere, that page will 403 [12:18] Similar to the blueprint issues, except 100x worse [12:19] And on just about every page of the application [12:19] we know this. we've discussed it at length, with both flacoste and sinzui. [12:19] They need to be fixed before we can think about having even a single private project on production. [12:19] Ubuntu's a couple of days away from final freeze [12:19] yeah, that's a fair point, though. [12:20] We cannot be breaking things now [12:20] It's fine if the alpha projects break the alpha projects [12:20] But at this stage they will break just about *everything*. [12:21] So even a closed alpha on production is extraordinarily risky [12:22] This is basically what happened with Abel's change that you reverted, except only for deactivated and not private projects? [12:22] Right [12:22] We already filter out deactivated projects in most places, but it *still* broke [12:22] We don't even try to filter out private projects anywhere yet [12:22] So it will be far worse [12:22] right [12:23] well, the alpha was more a symbolic release/early feedback kind of thing. to keep us on track. [12:23] we could just skip it and march on to beta. [12:23] wgrant: was this why madel couldnt see his LP page earlier on but could see his code page ? [12:23] Sure, it's really good to have a nice visible milestone like that. [12:24] And it's fine to be releasing unstable stuff onto production if the scope of the breakage is limited [12:24] But this is unlimited. Projects affect just about everything. [12:24] *mandel [12:24] czajkowski: Right [12:24] Person:+index is an example of a page that was broken in many cases by this [12:24] ah ok, but this won't affect people now as it's been reverted right. [12:24] czajkowski: Right [12:24] cheers [12:26] So yeah, the private project changes are looking good so far. But it's a really risky thing to be deploying, and we need to not take unnecessary risks particularly this close to an Ubuntu release [12:26] wgrant, I agree with you. I don't want to make the call entirely to kill the alpha without chatting with flacoste. But I don't see the point, given all that. [12:26] rick_h_, see my thoughts here ^^ [12:27] deryck: rgr, so my branch friday failed to land and I was going to get it fixed up this morning, but with the revert it seems there's a lot more work to do to get it to land [12:28] rick_h_, yes, there is. Take the holiday and don't worry about it. [12:28] deryck: so let me know what you think and I can work on it, but right now thinking of turning tail and regrouping with everyone tomorrow [12:28] deryck: ok [12:29] rick_h_, yeah, the others are not available today. Might as well regroup tomorrow. [12:35] rick_h_, are you still around? [12:39] deryck: Great [12:39] wgrant, thanks for reverting that work. sorry you guys were left to deal with it. [12:40] A lot of this stuff can be relatively easily discovered with a bit of nosing around qastaging, so I'm not sure we lose much non-psychological value from dropping/delaying the alpha [12:40] np, was easy to fix [12:40] yeah, agreed on the points one line back. === Ursinha-afk is now known as Ursinha [12:41] Although from working on disclosure I know how awful it can be for everyone to see no visible progress for weeks/months, so I understand the inclination to release early :) [12:46] Yeah. :) [12:46] And we need to release regularly to hit the timeline, since it's aggressive. But in this case, I don't think there's harm. [12:49] deryck: I am what's up? [12:50] rick_h_, why did you say the model was missing parts you needed? The revert changed the way we get information_type but that should be there still. What is missing? [12:51] deryck: so abel added the getter/setters on the information type [12:51] and I was using the setter [12:51] That should be fine [12:51] The setter just passed it through [12:51] I tried a quick change back to _information_type with the @property getter/setter but tests blew up all over [12:51] Perhaps the security configuration is broken [12:51] What's the error when you try to set it? [12:52] I was just starting to look into what was up when wgrant ping'd and all this started up [12:52] you would just set information_type directly now. [12:52] but as I say, you don't have to fix it now. we can regroup tomorrow. [12:52] sorry, closed up my lxc with the info. sec. [12:52] was just wondering what you were seeing. [12:52] yea, just some error from the db about _information_type not existing [12:52] so I assume there's something else to make the storm/query side happy witht he rename [12:53] Oh, if you're using it in a query then it'll matter, yeah [12:53] since I had changed the ENUM column to a leading understore for the getter/setter/property to wrap [12:53] For now you can just s/_information_type/information_type/ [12:53] Or that, yeah [12:54] wgrant: right, so shouldn't be anything huge I guess but I need to poke at what else is in that revision and such with the renames and all that [12:54] There were three minor conflicts, mostly in tests IIRC [12:54] But most stuff was pretty isolated. [12:55] cool [13:05] wgrant, so did the lp.view changes actually get released to lpnet? or you just reverted them from the stack of pending revisions to deploy? I didn't think we deployed at all last week. [13:06] deryck: It was deployed to lpnet a few hours ago [13:06] The appservers are presently reverted to the previous ndt (from Monday last week) [13:07] I immediately reverted the revision from devel, and there's an ndt scheduled for that [13:07] wgrant, ah, I follow now, thanks. === fjlacoste is now known as flacoste [13:07] Mostly so we can get the rest of the stuff out and check that none of us have broken anything else, before we add more revisions to the pile [13:07] flacoste was lurking and knows all. :) === wgrant changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: ~280 === Ursinha-afk is now known as Ursinha === deryck is now known as deryck[lunch] === Ursinha_ is now known as Ursinha === deryck[lunch] is now known as deryck [19:06] flacoste: hi, I'm around whenever you want to have our call [19:25] lifeless: i'm available now [19:25] cool === benji is now known as Guest8876 [21:44] wallyworld_: I guess the bugs.dynamic_bug_listings.enabled feature flag can be removed from prod? [21:45] rick_h_: At some point, you and I should remove js.combo_loader.enabled from the code [21:50] StevenK: yes [21:50] lifeless: O hai [21:50] now that my branch has deployed [21:50] lifeless: I'd like to remove bugs.dynamic_bug_listings.enabled and code.simplified_branches_menu.enabled from prod. The code no longer requires that they be set. Can haz approval? [21:51] StevenK: definitely, and jsbuild, and such [21:52] Death to jsbuild would make me very happy [21:52] sure [21:53] lifeless: Thanks [21:53] StevenK: it's more jsbuild/combobuild I think but some clean up required [21:54] rick_h_: Given the errors with yui-3.5.1 on build, certainly [21:58] wallyworld_: You've undone your python-boto fun from yesterday? [21:58] yep [21:59] 'fun' [21:59] FSVO, indeed [21:59] wallyworld_: Are we (being wgrant and myself) now one hour ahead of you? [21:59] yes :-( [22:06] StevenK: errors? [22:10] rick_h_: If you make and then make again, you see a bunch [23:48] Intriguing [23:48] My ec2 instance from 2am is still going [23:48] 9 hours later [23:48] Not hung, just very very slow [23:51] StevenK: So you removed all makeLegacyProduct calls in lib/lp/bugs? [23:52] wgrant: r16114 in my death-to-private_bugs branch [23:52] Great. [23:52] And you've rerun those tests to be sure they work? [23:54] Total: 39 tests, 0 failures, 0 errors in 50.183 seconds. [23:54] StevenK, wallyworld_: Do either of you feel like reviewing a 3800-line BVP elimination diff, or shall I self-review it? [23:54] StevenK: Great [23:55] i reckon self review. let the tests decide [23:55] Well, I also deleted a lot of tests. But I think I was pretty sensible, so I agree [23:55] wgrant: I'd like to glance at it, but I don't want to review it [23:56] You can't really "glance" at a 286KB diff [23:56] skim, then [23:57] demolish-bvp has no MP :-( [23:58] I was going to save Launchpad the effort if nobody dared review it [23:58] * wgrant proposes