=== skaet is now known as skaet__ [01:22] wallyworld: Oh good god, http://pastebin.ubuntu.com/1170963/ solves the test issues I brought up on the call. [01:22] yay [01:22] And I was the one who added filter_visible ... :-( [01:23] lol [01:23] that sort of thing happens to me too === gary_poster|away is now known as gary_poster [01:58] wallyworld, wgrant: https://code.launchpad.net/~stevenk/launchpad/drop-disclosure-feature-flags/+merge/121523 [01:58] +271? :( [01:59] what did you expect? it's a net loss of code [02:00] Well, normally I say "+foo? :(" then StevenK goes and reduces it to about 30% of that [02:00] I'm hoping it works here [02:00] Haha [02:00] Not this time [02:00] Far too much reflowing [02:01] :( [02:05] StevenK: I don't quite understand what's going on in bugsubscription.txt [02:05] Is there some broken unsubscription logic? [02:06] mr ocr - https://code.launchpad.net/~wallyworld/launchpad/branch-infotype-portlet-1040999/+merge/121404 https://code.launchpad.net/~wallyworld/launchpad/branch-infotype-portlet2-1040999/+merge/121527 [02:06] add to the queue :-) [02:06] Sure [02:07] thanks [02:08] food time, me hungry [02:08] I think I'll do the same after StevenK's branch [02:08] yeah, my branches will be in a huge bb queue anyway [02:10] Oh hm [02:10] No, that doesn't explain it [02:18] wgrant: I tried to explain it in the MP description. [02:19] wgrant: It seems the test subscribes mark, and then sets the bug to private, which boots mark off, and then the rest of test doesn't include him. [02:19] s/off, and/off, sets the bug back to public, and/ [02:19] But why has that changed? [02:20] Because I removed the section in transitionToInformationType that ripped out the subscriptions if the job feature flag was disabled [02:20] Since RASJ will do it [02:20] StevenK: Right, but shouldn't he have a grant from the sub? [02:21] The subs were only ripped out if there was no grant [02:21] wgrant: He was subscribed when the bug was public -> no grant [02:22] Oh, right [02:23] Makes sense, then [02:23] But please do dispose of enhanced_picker fully [02:24] Eh? I missed something? [02:24] 69 @property [02:24] 70 def enhanced_picker(self): [02:24] Oh, that should get pulled in properly. Right. [02:30] wallyworld: tossed a side note out to your MP [02:30] * wallyworld looks [02:31] rick_h_: agreed 100%, but this branch is more concerned with extending existing code to deliver what's required rather than fixing the inherit design issues [02:32] now that the core banner stuff is out, it can be decoupled later [02:32] wallyworld: ok, yea just gave it a quick glance and seemed to introduce some new stuff in the information type stuff for code. [02:32] wallyworld: cool, ok [02:32] yeah, that was to avoid code duplication with what was there already [02:32] thanks for looking though [02:33] with this can you use the BranchInformationTypeWidget without a portlet/banner? [02:33] e.g. from the actual edit UI for a branch or bug? I guess you'd have to since I've seen the bug UI have it as a normal UI field in edit [02:35] rick_h_: the banner etc is currently expected to be there since it makes direct calls to the various methods [02:36] the portlet is expected to be there and that's what the widget is manipulating [02:36] wallyworld: ok, I guess I'll be peeking at it soon enough. I was thinking of the case of during bug submission/etc [02:37] it's not relevant during bug submission [02:37] it's only for editng the info type via the bug/branch overview pages [02:37] ok, so the widget for selecting information type during submission is a different widget? /me hasn't gotten down to all the code yet [02:38] yes - the one during submission is just a popup field, the one on the overview pages is a portlet with extra info rendered [02:39] extra info = description [02:39] ah ok. I'll peek at it again in the morning then. Thanks. [02:39] rick_h_: so with yui 3.5, i notice Y.Lang.substitute is replaced in some places by Y.Lang.sub [02:40] yea, substitute is on the way to deprecation I think. Those will probably have to be updated. [02:40] ah ok. thanks. i was really happy to see we are on 3.5 \o/ [02:40] there's discussion of a micro template feature added into 3.7 that would replace sub all together and be something less than handlebars, but more than sub [02:40] and soon 3.6 maybe :-) [02:41] cool, sounds good [02:41] Speaking of 3.5 [02:41] yea, I already had tests for 3.5.1 and 3.6 was new enough I didn't want to jump that far [02:41] I haven't seen any issues [02:41] Should we deploy it to everyone? :) [02:41] cool, I'll open it up to beta tests later this week [02:41] beta usres [02:41] beta users...gah late here [02:41] very late [02:41] we have to wait for the RT on the squid proxy before we can enable the combo loader for all users and then get everyone on 3.5...hopefully in a month [02:42] Oh, we can't do non-comboloaded 3.5? [02:42] no, we can't [02:42] :( [02:42] well, not without a lot of extra work [02:42] and we're one RT from combo loader for all so holding onto that and then it's a non-issue any more [02:42] should make the upgrade to 3.6 a very easy process [02:44] Yep [02:44] the only big missing part after that is some way of running our JS tests on each version we have running [02:44] what's the rt for? caching? [02:45] yea, combo loader wsgi traffic caused a 1-2% cpu spike on the app servers it's running on. [02:45] since the urls never change (they're unique per revid) they can be 100% cached in squid [02:45] right, sounds logical [02:45] and should cause no real load for us at that point [02:46] got an email that someone was oging to work on it after the DC move, but we know how much fnu that's been :) [02:52] wallyworld: Oh right, we can use set literals now, can't we... [02:52] yeah [02:53] i just did it as a drive by [02:53] wallyworld: Why do we use a custom form for this widget, rather than the API? [02:53] so i can re use all the existing back end logic [02:53] to keep html and ajax back end code the same [02:54] and for bugs, the form returns the subscribers list. we will ultimately need to do that for branches too [02:54] The only thing that should be interesting to share is getInformationTypesToShow, right? [02:54] Still, there has to be a better solution to that [02:55] maybe. code reuse is good :-) [02:55] Yes [02:55] But doing it through a custom form isn't :) [02:55] why? [02:55] it is a form submission type operation [02:55] I think this is the only case where we don't use the API [02:55] Everything else does [02:55] Even milestone creation [02:55] and we get to use all the existing validation hooks, error handling etc [02:56] Milestone creation loads a form from the server, but then submits via the API [02:56] wallyworld: Sure, but we need the validation hooks and error handling through the API too [02:56] What does the form need that the API doesn't? [02:56] bug privacy also works this way [02:56] Sure [02:56] That's the one exception [02:56] In all of Launchpad [02:56] To the rule [02:56] I understand that you're cloning bug privacy [02:57] But I think bug privacy is very wrong [02:57] i disagree :-) [02:57] Everything else manages to use the API [02:57] The only possibly valid argument is the custom return value [02:58] Validation/errorhandling are not valid arguments, since the API needs those too [02:58] the form infrastructure is what's being used here - why does the transport matter? [02:58] If the API isn't sufficient, we probably have a problem with our API [02:59] And it'd be nice to understand what that problem is :) [02:59] does the api have declarative validation hooks and all the rest of the stuff that the form submisison stuff relies on? [03:00] We expose this exact transition as an API method [03:00] If that API method doesn't do the necessary validation, we have a serious bug [03:01] bugs checks that a bug is being made invisible, and there's a workflow there to manage that with the user [03:01] you can't really do that via the api in the same way [03:01] Why not? [03:01] so you need some front end to handle that [03:01] You have the current bug state in the JS [03:01] You know the new state because the user clicked on it [03:02] yes, but the api has to communicate the potential issue back to the caller and then process their response [03:02] Well, the API can either do that by accepting a keyword arg for confirmation [03:02] Or, and this would be my preference, the web UI does the check before it gets to the API [03:03] 2 xhr calls = yuck [03:03] Huh? [03:03] How's that different from now? [03:03] well one to check,one to do the work [03:03] You don't necessarily need one for the check [03:03] now, it optimistically assumes it will succeed [03:03] Since you have the old and new information_types [03:04] On the client [03:04] the client can't make the decision [03:04] Why not? [03:04] it doesn't have all the information [03:04] a back end sharing service api call is required [03:05] Oh, right, we only warn if there's no APG? [03:05] Forgot that detail [03:05] A way to do that with one API call is to have an even_if_there_is_no_apg=False kwarg [03:05] So the normal case would be a single call [03:05] On failure, retry setting that to True [03:06] at the end of the day, both ajax widget and html form are the same thing - submit of data to be processed, so should be handled consistently by the back end [03:07] But the API needs that too [03:07] using common code [03:07] So the validation code has to be in the model [03:07] Not the view [03:07] here it's no so much validation as in a check that's only relevant to the ui at the monent [03:08] and the check is done using model code [03:08] Right, this is an interesting special case [03:08] But I don't think it's special enough to warrant not using the API, if this wasn't just a clone of the Bugs code [03:09] the view layer is a logical thing to use to solve any impedance mismatch between web and model api [03:09] Probably, yes [03:09] But not as the application is architected at present [03:10] especially with html forms for the exact same editing operation is use [03:10] we want to keep the code common [03:12] Right, we need a way to do that [03:12] But currently we don't do it in many places [03:12] if no html form was there, then i'd have used the api since all the view code would be in javascript [03:12] And when we need to, it involves adding self.request.is_ajax special-cases everywhere [03:13] the is_ajax is just used to determine what to return from the actions [03:13] Sure [03:13] And the fact we have to repeatedly hack this in is a sign that we're Doing it Wrong™ [03:13] ideally there would be no html forms, just ajax :-) [03:14] Indeed [03:14] and then the issue would be moot [03:18] wgrant: bug 1040989 "For commercial projects we can choose Public or Proprietary as the default...." - this seems to imply just to check for OTHER_PROPRIETARY when registering a project, but surely a commercial subscription is also required to allow proprietary sharing policies? [03:18] <_mup_> Bug #1040989: new project have legacy sharing policies < https://launchpad.net/bugs/1040989 > [03:19] wallyworld: Projects with Other/Proprietary get a complimentary 30 day commercial subscription. [03:19] I'm not sure at which stage this is applied [03:19] ah ok,thanks [03:20] i'll look into it [03:20] Personally I think we might be best to just always default to Public/Public for now [03:20] But if it looks easy, I guess the Proprietary defaults couldn't hurt [03:21] i'm doing it because the card was put into the next lane as an item to do to finalise stuff for the beta [03:21] so i assume it's required [03:21] The really important bit is that it not default to legacy any more [03:22] Since we want to be migrating existing projects away from legacy without creating new ones [03:22] yes, true [03:22] We can't make the columns NOT NULL if new projects have them null [03:22] That's the main thing [03:42] StevenK: Hah [03:42] StevenK: I just tripped over the makeBug(product=) thing myself [03:50] Hahaha [03:53] wgrant: another one to add to your queue, sorry https://code.launchpad.net/~wallyworld/launchpad/new-project-sharing-policies-1040989/+merge/121532 [03:53] Oh, that was easier than expected [03:54] hope i haven't missed anything [03:54] Nope, r=me [03:54] Thanks [03:54] coo :-) [03:55] cool [03:55] luckily createProduct calles setLicence which does the subscription thing [03:55] Yup [03:55] Not quite sure how we're going to do the not-null thing [03:55] But I guess whoever does that can work it out :) [03:58] wgrant: Your comment on the MP pre-dates our discussion about bugsubscription.txt? [03:59] StevenK: It was between me asking and you responding, so yes, that's no longer a concern [03:59] wallyworld: http://pastebin.ubuntu.com/1171109/ [04:00] wallyworld: Opinions, have I missed something/looks okay? [04:00] * wallyworld looks [04:06] wallyworld, wgrant: Now the deploy is done, any reason I can't toss my branch that ALTER TABLE product/distribution DROP COLUMN security_contact at ec2 to land? [04:07] StevenK: db-devel has enough stuff in it already [04:07] There's already two things, AFAIK [04:07] Let's not add more [04:07] StevenK: 99 - show_create_team=self.enhanced_picker) [04:08] should be show_create_team=self.show_create_team) [04:09] Hmmm, I think show_create_team_link in that class can die too [04:10] Mmm, maybe not [04:10] you need to keep the show_create_team boolean [04:10] StevenK: also, in test_vocabulary, you can delete tests [04:11] the tests without enhanced_picker=True which have matching =True versions can go [04:11] and maybe rename the tests to remove _enhanced_ fromthe name [04:12] looks ok otherwise, but do run it up locally and test project creation and editing of owwner/driver [04:13] wallyworld: Not sure which tests can die, but http://pastebin.ubuntu.com/1171125/ [04:15] StevenK: i'm not sure either, ignore that dumb comment of mine. i think it looks ok [04:27] wgrant: distributions don't have bug/branch sharing policies yet, right? [04:33] wallyworld: I just tried New Team. It looks *awesome* [04:34] StevenK: oh, cool, ta :-) [04:34] wallyworld: It needed to be 'show_create_team=self.show_create_team_link' anyway [04:35] ah, right, sorry. i misrembered [04:35] The tests picked it up [04:35] so the create team link should only be there for registering new projects and editing owners/drivers [04:35] yay for tests \o/ [04:36] wallyworld: Yeah, I tried assigning a bug and there was no create team link [04:36] good! [04:36] Rargh [04:37] oh no, what? [04:37] Damn it, auditor, stop failing on db-devel :-( [04:37] Now wallyworld will yell at me again :-( [04:37] i didn't yell :-) [04:37] just asked politely [04:37] I know, I'm teasing [04:38] irc is so devoid of emotional clues [04:38] Hold on, I'll get in the car and drive 12 hours. Will that help? [04:39] ok, and bring cake [04:39] You don't deserve any, due to being a large cake tease with spm. [04:40] i actually made one and sent him a picture :-D [04:40] it was sooo yummy too [04:40] Yes, but he didn't get to eat any! [04:40] i know! hence the :-D [04:40] i was trolling him [04:48] And then devel fails with test_getAllPermissions_constant_query_count [04:48] Seriously [04:48] This is why we can't have nice things. [04:51] i think the query count test was added relatively recently [04:52] wgrant was talking about it yesterday [04:53] yeah, it's all soyuz fault [05:29] wgrant: Terribly hard review up for you. https://code.launchpad.net/~stevenk/launchpad/clean-up-ibranch/+merge/121536 [05:33] Oooh, Postgres 9.2 RC1 [05:34] yeah, yeah. [05:35] stub: Not a dig at you, just reading the blog post [05:35] haha, yeah. Just don't get too excited :) [05:36] There is some cool stuff in there though, such as statement profiling that might actually work for us. Nice to have pg spit out our slowest common queries. [05:36] 'Fix bugs in pg_trgm' looks relevant too [06:03] wallyworld: Since wgrant appears to have disappeared without a trace, can you review https://code.launchpad.net/~stevenk/launchpad/clean-up-ibranch/+merge/121536 ? A few tears would be okay, too, since it's the last mention of transitively_private in model code. [06:43] StevenK: sorry, was out buying dinner, looking now [06:49] StevenK: there's still a update_transitively_private Postgres function? Which updates Branch table transitively_private column. And there's also a security.cfg entry for said function. [06:49] i guess these will be killed next [06:50] r=me [06:50] I thought that was dead [06:52] ALTER TABLE Branch DROP COLUMN transitively_private; [06:52] DROP TRIGGER maintain_branch_transitive_privacy_t ON Branch; [06:52] DROP FUNCTION maintain_transitively_private(); [06:52] In 16-6 [06:53] steven@undermined:~/launchpad/lp-branches/clean-up-ibranch% grep -c maintain_transitively_private database/schema/security.cfg [06:53] 0 [07:23] StevenK: in security.cfg, look for public.update_transitively_private(integer, integer, boolean) = [07:29] With no perms [07:30] But yeah [07:47] good morning === frankban changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: frankban | Firefighting: - | Critical bugs: 4.0*10^2 [08:03] mgz: morning, /wave jelmer [08:04] hello mgz, jam [08:04] I'm technically off today, but I'd like to chat with you guys on mumble if you're available. [08:05] I'll hop on === almaisan-away is now known as al-maisan === jamestunnicliff_ is now known as jamestunnicliffe === smartboyhw_ is now known as smartboyhw === rick_h_ changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: frankban, rick_h | Firefighting: - | Critical bugs: 4.0*10^2 [10:33] jelmer: so, I take it this is not the intended plan with the lucid/py27 ppa: [10:34] mgz: hehe, no [10:34] it also needs the normal launchpad ppas, and to upgrade everything? [10:34] or should just leave those packages alone? [10:35] mgz: it should leave those packages alone [10:36] mgz: are you looking at the bzr 2.5.1 upgrade, or should I ? [10:37] I can do that. [10:38] mgz: either works for me; I'm a bit stuck with the python upgrade, the bzr 2.5.1 upgrade seems more straightforward [10:38] Which PPA is this? https://launchpad.net/~canonical-bazaar/+archive/py27/+packages ? If so, I'd be quite surprised if you were able to get away with versioning python-defaults as 2.7anything, rather than 2.6something [10:39] * maxb has battle scars from backporting Python 2.7 to Debian etch. [10:39] Yes, etc. [10:39] h [10:40] maxb: that sounds painful [10:40] It was... interesting :-) [10:40] mgz: why is that? [10:42] * mgz reads maxb's mind [10:43] So why aren't we just switching to Precise? The machines are all due for that upgrade anyway. [10:44] stub: this is what I keep asking. [10:44] it's meant to be 'easier' and 'safer' to do all this crazy backport stuff with packages no one else has used or needs [10:45] but seems like it's just introducing yet another environment for things to potentially fail in. [10:45] I don't see how using untested bespoke packages is considered safer than the versions all the devs have been testing for months. [10:45] indeed. [10:46] Especially if there do turn out to be problems, the solution would be to upgrade to precise rather than stick with 2.6 forever. [10:51] On a similar topic, why not precise/py26 rather than lucid/py27? [10:56] we know that we're broken on 2.7 atm AFAIK. [10:56] calling it tested for months is a massive exaggeration. [10:57] maxb: because its a lot easier to rollback lucid/py27. [10:57] broken in non-testsuite ways? I'm reasonably sure I got all the test failures. [10:58] yes [10:58] lifeless: Fair enough - on the other hand, it's probably a lot easier to create a viable precise/py26 PPA than a lucid/py27 one [10:59] maxb: we depend on very few system packages [10:59] hmm, ok, I was just looking at canonical-bazaar/py27 and noticing an awful lot of red Xes [11:01] If we are broken under 2.7, we are broken under 2.7. At least with Precise we know it is broken with the real environment, not a bespoke environment. [11:01] * lifeless shrugs [11:01] we had a disasterous time last time we did a lock step upgrade. [11:03] But we are switching to 2.7 plus all our packages, which is pretty much a lock step upgrade. Except we are planning on doing it twice. [11:03] stub: how do you figure that ? [11:04] Once to a version of 2.7 nobody except staging and buildbot will be using, plus lucid debs. Then again to Precise 2.7. [11:04] many devs develop on lucid in lxc; so nobody is an exaggeration. But sure. [11:04] There are two separate transitions. [11:05] There were three. [11:06] postgresql [11:06] python [11:06] base os [11:07] we did the same strategy for postgresql. [11:08] and the associated libraries [11:08] and we had small issues and friction [11:08] postgresql is unrelated, as that is server migration. [11:09] its entirely related; we had to deal with it in buildbot, we had to upgrade libpq because of (I forget the exact issue) [11:09] We *want* things to fail under buildbot and staging. What we are worried about is production failures, and there is unrelated. [11:10] if it was unrelated, we wouldn't have had to upgrade packages on all the production machines :) [11:11] It is unrelated because the DB servers are due for upgrade to Precise as soon as webops have bandwidth. It isn't blocked on the clients. [11:11] they are *now* [11:11] I'm not talking about precise on those servers [11:11] I'm talking about 8.4->9.1 [11:11] which was part of the overall upgrade-to-precise plan [11:23] stub: thanks for the review [11:49] stub: FYI in 9.1 we can now add constraints without too much downtime [11:49] Using NOT VALID [11:49] Then ALTER TABLE ... VALIDATE CONSTRAINT [11:50] That may influence your opinion on adeuring's MP [11:54] Oh, hadn't seen that. Ta. [11:54] shiny [11:55] Its only 100k rows to scan [11:56] True [11:56] But yeah [11:56] that was a relatively late addition to 9.1 [11:56] It was the last common really expensive operation [11:56] that is now doable without major downtime [11:56] makes me very happy [11:59] 100k rows is probably too many [12:00] Yeah [12:00] Well [12:00] It's only validation [12:00] And it's pretty simple [12:00] So it might be OK [12:00] But I think you're still probably looking at >5s for that [12:00] But I haven't thought that through properly === gary_poster is now known as gary_poster|away [12:02] I'm fairly sure we would be [12:02] but data will tell [12:02] I'd sort of expect 5-10s for a single node there [12:03] but that's mostly a gut feeling [12:03] I see progress from stub on rolling schema patches. [12:03] oh? [12:03] which will be awesome [12:03] oh [12:03] you mean nodowntimefastdowntime? [12:03] nearlynodowntimefastdowntime [12:03] right [12:03] noreaddowntime [12:03] yeah [12:03] we discussed that last night [12:03] great. [12:03] i saw a branch [12:04] looks ok [12:04] I should spend more time not looking in the channel, you guys get up to good stuff :) [12:04] it will be marvellous :) [12:04] stub: sorry I didn't catch up w/ you last week, was -hectic-. [12:04] stub: this week may be too, for different reasons. [12:04] And in Sydney [12:04] stub: if you want to catch up, wed is probably the day, or we can raincheck it - whatever you prefer [12:05] *yawn*, ciao. [12:05] lifeless: whatever :) [12:06] see how we go tomorrow [12:06] Night lifeless [12:08] and from above, just about to push the tests. === gary_poster|away is now known as gary_poster [12:11] stub: yeah, i'm glad we have pgbouncer fixtures working so we can actually test that excellently [12:11] this is not the sort of stuff we want untested [12:31] mgz: you about? [12:35] yup [12:36] will need some lunch shortly though. [12:36] mgz: can you look at https://bugs.launchpad.net/launchpad/+bug/1042351 when you're free please [12:36] <_mup_> Bug #1042351: Bzr import fails with NotImplementedError in broken_remote_exceptions < https://launchpad.net/bugs/1042351 > [12:36] else I'll poke jelmer when he gets back [12:41] it's an old format, which may upset things, otherwise need to look at logs/code for more info === al-maisan is now known as almaisan-away [13:48] abentley: let me know if there's anything I can do to help ease the JS pain in that stuff. [13:48] rick_h_: Thanks. === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === deryck is now known as deryck[lunch] === almaisan-away is now known as al-maisan === matsubara is now known as matsubara-lunch === deryck[lunch] is now known as deryck === matsubara-lunch is now known as matsubara === al-maisan is now known as almaisan-away [19:29]