| === skaet is now known as skaet__ | ||
| StevenK | wallyworld: Oh good god, http://pastebin.ubuntu.com/1170963/ solves the test issues I brought up on the call. | 01:22 |
|---|---|---|
| wallyworld | yay | 01:22 |
| StevenK | And I was the one who added filter_visible ... :-( | 01:22 |
| wallyworld | lol | 01:23 |
| wallyworld | that sort of thing happens to me too | 01:23 |
| === gary_poster|away is now known as gary_poster | ||
| StevenK | wallyworld, wgrant: https://code.launchpad.net/~stevenk/launchpad/drop-disclosure-feature-flags/+merge/121523 | 01:58 |
| wgrant | +271? :( | 01:58 |
| wallyworld | what did you expect? it's a net loss of code | 01:59 |
| wgrant | Well, normally I say "+foo? :(" then StevenK goes and reduces it to about 30% of that | 02:00 |
| wgrant | I'm hoping it works here | 02:00 |
| StevenK | Haha | 02:00 |
| StevenK | Not this time | 02:00 |
| StevenK | Far too much reflowing | 02:00 |
| wgrant | :( | 02:01 |
| wgrant | StevenK: I don't quite understand what's going on in bugsubscription.txt | 02:05 |
| wgrant | Is there some broken unsubscription logic? | 02:05 |
| wallyworld | 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 |
| wallyworld | add to the queue :-) | 02:06 |
| wgrant | Sure | 02:06 |
| wallyworld | thanks | 02:07 |
| wallyworld | food time, me hungry | 02:08 |
| wgrant | I think I'll do the same after StevenK's branch | 02:08 |
| wallyworld | yeah, my branches will be in a huge bb queue anyway | 02:08 |
| wgrant | Oh hm | 02:10 |
| wgrant | No, that doesn't explain it | 02:10 |
| StevenK | wgrant: I tried to explain it in the MP description. | 02:18 |
| StevenK | 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 |
| StevenK | s/off, and/off, sets the bug back to public, and/ | 02:19 |
| wgrant | But why has that changed? | 02:19 |
| StevenK | Because I removed the section in transitionToInformationType that ripped out the subscriptions if the job feature flag was disabled | 02:20 |
| StevenK | Since RASJ will do it | 02:20 |
| wgrant | StevenK: Right, but shouldn't he have a grant from the sub? | 02:20 |
| wgrant | The subs were only ripped out if there was no grant | 02:21 |
| StevenK | wgrant: He was subscribed when the bug was public -> no grant | 02:21 |
| wgrant | Oh, right | 02:22 |
| wgrant | Makes sense, then | 02:23 |
| wgrant | But please do dispose of enhanced_picker fully | 02:23 |
| StevenK | Eh? I missed something? | 02:24 |
| wgrant | 69 @property | 02:24 |
| wgrant | 70 def enhanced_picker(self): | 02:24 |
| StevenK | Oh, that should get pulled in properly. Right. | 02:24 |
| rick_h_ | wallyworld: tossed a side note out to your MP | 02:30 |
| * wallyworld looks | 02:30 | |
| wallyworld | 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:31 |
| wallyworld | now that the core banner stuff is out, it can be decoupled later | 02:32 |
| rick_h_ | 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 |
| rick_h_ | wallyworld: cool, ok | 02:32 |
| wallyworld | yeah, that was to avoid code duplication with what was there already | 02:32 |
| wallyworld | thanks for looking though | 02:32 |
| rick_h_ | with this can you use the BranchInformationTypeWidget without a portlet/banner? | 02:33 |
| rick_h_ | 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:33 |
| wallyworld | rick_h_: the banner etc is currently expected to be there since it makes direct calls to the various methods | 02:35 |
| wallyworld | the portlet is expected to be there and that's what the widget is manipulating | 02:36 |
| rick_h_ | wallyworld: ok, I guess I'll be peeking at it soon enough. I was thinking of the case of during bug submission/etc | 02:36 |
| wallyworld | it's not relevant during bug submission | 02:37 |
| wallyworld | it's only for editng the info type via the bug/branch overview pages | 02:37 |
| rick_h_ | 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:37 |
| wallyworld | yes - the one during submission is just a popup field, the one on the overview pages is a portlet with extra info rendered | 02:38 |
| wallyworld | extra info = description | 02:39 |
| rick_h_ | ah ok. I'll peek at it again in the morning then. Thanks. | 02:39 |
| wallyworld | rick_h_: so with yui 3.5, i notice Y.Lang.substitute is replaced in some places by Y.Lang.sub | 02:39 |
| rick_h_ | yea, substitute is on the way to deprecation I think. Those will probably have to be updated. | 02:40 |
| wallyworld | ah ok. thanks. i was really happy to see we are on 3.5 \o/ | 02:40 |
| rick_h_ | 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 |
| wallyworld | and soon 3.6 maybe :-) | 02:40 |
| wallyworld | cool, sounds good | 02:41 |
| wgrant | Speaking of 3.5 | 02:41 |
| rick_h_ | 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 |
| wgrant | I haven't seen any issues | 02:41 |
| wgrant | Should we deploy it to everyone? :) | 02:41 |
| rick_h_ | cool, I'll open it up to beta tests later this week | 02:41 |
| rick_h_ | beta usres | 02:41 |
| rick_h_ | beta users...gah late here | 02:41 |
| wallyworld | very late | 02:41 |
| rick_h_ | 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:41 |
| wgrant | Oh, we can't do non-comboloaded 3.5? | 02:42 |
| rick_h_ | no, we can't | 02:42 |
| wgrant | :( | 02:42 |
| rick_h_ | well, not without a lot of extra work | 02:42 |
| rick_h_ | 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 |
| rick_h_ | should make the upgrade to 3.6 a very easy process | 02:42 |
| wgrant | Yep | 02:44 |
| rick_h_ | the only big missing part after that is some way of running our JS tests on each version we have running | 02:44 |
| wallyworld | what's the rt for? caching? | 02:44 |
| rick_h_ | yea, combo loader wsgi traffic caused a 1-2% cpu spike on the app servers it's running on. | 02:45 |
| rick_h_ | since the urls never change (they're unique per revid) they can be 100% cached in squid | 02:45 |
| wallyworld | right, sounds logical | 02:45 |
| rick_h_ | and should cause no real load for us at that point | 02:45 |
| rick_h_ | 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:46 |
| wgrant | wallyworld: Oh right, we can use set literals now, can't we... | 02:52 |
| wallyworld | yeah | 02:52 |
| wallyworld | i just did it as a drive by | 02:53 |
| wgrant | wallyworld: Why do we use a custom form for this widget, rather than the API? | 02:53 |
| wallyworld | so i can re use all the existing back end logic | 02:53 |
| wallyworld | to keep html and ajax back end code the same | 02:53 |
| wallyworld | and for bugs, the form returns the subscribers list. we will ultimately need to do that for branches too | 02:54 |
| wgrant | The only thing that should be interesting to share is getInformationTypesToShow, right? | 02:54 |
| wgrant | Still, there has to be a better solution to that | 02:54 |
| wallyworld | maybe. code reuse is good :-) | 02:55 |
| wgrant | Yes | 02:55 |
| wgrant | But doing it through a custom form isn't :) | 02:55 |
| wallyworld | why? | 02:55 |
| wallyworld | it is a form submission type operation | 02:55 |
| wgrant | I think this is the only case where we don't use the API | 02:55 |
| wgrant | Everything else does | 02:55 |
| wgrant | Even milestone creation | 02:55 |
| wallyworld | and we get to use all the existing validation hooks, error handling etc | 02:55 |
| wgrant | Milestone creation loads a form from the server, but then submits via the API | 02:56 |
| wgrant | wallyworld: Sure, but we need the validation hooks and error handling through the API too | 02:56 |
| wgrant | What does the form need that the API doesn't? | 02:56 |
| wallyworld | bug privacy also works this way | 02:56 |
| wgrant | Sure | 02:56 |
| wgrant | That's the one exception | 02:56 |
| wgrant | In all of Launchpad | 02:56 |
| wgrant | To the rule | 02:56 |
| wgrant | I understand that you're cloning bug privacy | 02:56 |
| wgrant | But I think bug privacy is very wrong | 02:57 |
| wallyworld | i disagree :-) | 02:57 |
| wgrant | Everything else manages to use the API | 02:57 |
| wgrant | The only possibly valid argument is the custom return value | 02:57 |
| wgrant | Validation/errorhandling are not valid arguments, since the API needs those too | 02:58 |
| wallyworld | the form infrastructure is what's being used here - why does the transport matter? | 02:58 |
| wgrant | If the API isn't sufficient, we probably have a problem with our API | 02:58 |
| wgrant | And it'd be nice to understand what that problem is :) | 02:59 |
| wallyworld | does the api have declarative validation hooks and all the rest of the stuff that the form submisison stuff relies on? | 02:59 |
| wgrant | We expose this exact transition as an API method | 03:00 |
| wgrant | If that API method doesn't do the necessary validation, we have a serious bug | 03:00 |
| wallyworld | bugs checks that a bug is being made invisible, and there's a workflow there to manage that with the user | 03:01 |
| wallyworld | you can't really do that via the api in the same way | 03:01 |
| wgrant | Why not? | 03:01 |
| wallyworld | so you need some front end to handle that | 03:01 |
| wgrant | You have the current bug state in the JS | 03:01 |
| wgrant | You know the new state because the user clicked on it | 03:01 |
| wallyworld | yes, but the api has to communicate the potential issue back to the caller and then process their response | 03:02 |
| wgrant | Well, the API can either do that by accepting a keyword arg for confirmation | 03:02 |
| wgrant | Or, and this would be my preference, the web UI does the check before it gets to the API | 03:02 |
| wallyworld | 2 xhr calls = yuck | 03:03 |
| wgrant | Huh? | 03:03 |
| wgrant | How's that different from now? | 03:03 |
| wallyworld | well one to check,one to do the work | 03:03 |
| wgrant | You don't necessarily need one for the check | 03:03 |
| wallyworld | now, it optimistically assumes it will succeed | 03:03 |
| wgrant | Since you have the old and new information_types | 03:03 |
| wgrant | On the client | 03:04 |
| wallyworld | the client can't make the decision | 03:04 |
| wgrant | Why not? | 03:04 |
| wallyworld | it doesn't have all the information | 03:04 |
| wallyworld | a back end sharing service api call is required | 03:04 |
| wgrant | Oh, right, we only warn if there's no APG? | 03:05 |
| wgrant | Forgot that detail | 03:05 |
| wgrant | A way to do that with one API call is to have an even_if_there_is_no_apg=False kwarg | 03:05 |
| wgrant | So the normal case would be a single call | 03:05 |
| wgrant | On failure, retry setting that to True | 03:05 |
| wallyworld | 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:06 |
| wgrant | But the API needs that too | 03:07 |
| wallyworld | using common code | 03:07 |
| wgrant | So the validation code has to be in the model | 03:07 |
| wgrant | Not the view | 03:07 |
| wallyworld | here it's no so much validation as in a check that's only relevant to the ui at the monent | 03:07 |
| wallyworld | and the check is done using model code | 03:08 |
| wgrant | Right, this is an interesting special case | 03:08 |
| wgrant | 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:08 |
| wallyworld | the view layer is a logical thing to use to solve any impedance mismatch between web and model api | 03:09 |
| wgrant | Probably, yes | 03:09 |
| wgrant | But not as the application is architected at present | 03:09 |
| wallyworld | especially with html forms for the exact same editing operation is use | 03:10 |
| wallyworld | we want to keep the code common | 03:10 |
| wgrant | Right, we need a way to do that | 03:12 |
| wgrant | But currently we don't do it in many places | 03:12 |
| wallyworld | if no html form was there, then i'd have used the api since all the view code would be in javascript | 03:12 |
| wgrant | And when we need to, it involves adding self.request.is_ajax special-cases everywhere | 03:12 |
| wallyworld | the is_ajax is just used to determine what to return from the actions | 03:13 |
| wgrant | Sure | 03:13 |
| wgrant | And the fact we have to repeatedly hack this in is a sign that we're Doing it Wrong™ | 03:13 |
| wallyworld | ideally there would be no html forms, just ajax :-) | 03:13 |
| wgrant | Indeed | 03:14 |
| wallyworld | and then the issue would be moot | 03:14 |
| wallyworld | 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 <disclosure> <sharing> <Launchpad itself:In Progress by wallyworld> < https://launchpad.net/bugs/1040989 > | 03:18 |
| wgrant | wallyworld: Projects with Other/Proprietary get a complimentary 30 day commercial subscription. | 03:19 |
| wgrant | I'm not sure at which stage this is applied | 03:19 |
| wallyworld | ah ok,thanks | 03:19 |
| wallyworld | i'll look into it | 03:20 |
| wgrant | Personally I think we might be best to just always default to Public/Public for now | 03:20 |
| wgrant | But if it looks easy, I guess the Proprietary defaults couldn't hurt | 03:20 |
| wallyworld | 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 |
| wallyworld | so i assume it's required | 03:21 |
| wgrant | The really important bit is that it not default to legacy any more | 03:21 |
| wgrant | Since we want to be migrating existing projects away from legacy without creating new ones | 03:22 |
| wallyworld | yes, true | 03:22 |
| wgrant | We can't make the columns NOT NULL if new projects have them null | 03:22 |
| wgrant | That's the main thing | 03:22 |
| wgrant | StevenK: Hah | 03:42 |
| wgrant | StevenK: I just tripped over the makeBug(product=) thing myself | 03:42 |
| StevenK | Hahaha | 03:50 |
| wallyworld | wgrant: another one to add to your queue, sorry https://code.launchpad.net/~wallyworld/launchpad/new-project-sharing-policies-1040989/+merge/121532 | 03:53 |
| wgrant | Oh, that was easier than expected | 03:53 |
| wallyworld | hope i haven't missed anything | 03:54 |
| wgrant | Nope, r=me | 03:54 |
| wgrant | Thanks | 03:54 |
| wallyworld | coo :-) | 03:54 |
| wallyworld | cool | 03:55 |
| wallyworld | luckily createProduct calles setLicence which does the subscription thing | 03:55 |
| wgrant | Yup | 03:55 |
| wgrant | Not quite sure how we're going to do the not-null thing | 03:55 |
| wgrant | But I guess whoever does that can work it out :) | 03:55 |
| StevenK | wgrant: Your comment on the MP pre-dates our discussion about bugsubscription.txt? | 03:58 |
| wgrant | StevenK: It was between me asking and you responding, so yes, that's no longer a concern | 03:59 |
| StevenK | wallyworld: http://pastebin.ubuntu.com/1171109/ | 03:59 |
| StevenK | wallyworld: Opinions, have I missed something/looks okay? | 04:00 |
| * wallyworld looks | 04:00 | |
| StevenK | 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:06 |
| wgrant | StevenK: db-devel has enough stuff in it already | 04:07 |
| wgrant | There's already two things, AFAIK | 04:07 |
| wgrant | Let's not add more | 04:07 |
| wallyworld | StevenK: 99 - show_create_team=self.enhanced_picker) | 04:07 |
| wallyworld | should be show_create_team=self.show_create_team) | 04:08 |
| StevenK | Hmmm, I think show_create_team_link in that class can die too | 04:09 |
| StevenK | Mmm, maybe not | 04:10 |
| wallyworld | you need to keep the show_create_team boolean | 04:10 |
| wallyworld | StevenK: also, in test_vocabulary, you can delete tests | 04:10 |
| wallyworld | the tests without enhanced_picker=True which have matching =True versions can go | 04:11 |
| wallyworld | and maybe rename the tests to remove _enhanced_ fromthe name | 04:11 |
| wallyworld | looks ok otherwise, but do run it up locally and test project creation and editing of owwner/driver | 04:12 |
| StevenK | wallyworld: Not sure which tests can die, but http://pastebin.ubuntu.com/1171125/ | 04:13 |
| wallyworld | StevenK: i'm not sure either, ignore that dumb comment of mine. i think it looks ok | 04:15 |
| wallyworld | wgrant: distributions don't have bug/branch sharing policies yet, right? | 04:27 |
| StevenK | wallyworld: I just tried New Team. It looks *awesome* | 04:33 |
| wallyworld | StevenK: oh, cool, ta :-) | 04:34 |
| StevenK | wallyworld: It needed to be 'show_create_team=self.show_create_team_link' anyway | 04:34 |
| wallyworld | ah, right, sorry. i misrembered | 04:35 |
| StevenK | The tests picked it up | 04:35 |
| wallyworld | so the create team link should only be there for registering new projects and editing owners/drivers | 04:35 |
| wallyworld | yay for tests \o/ | 04:35 |
| StevenK | wallyworld: Yeah, I tried assigning a bug and there was no create team link | 04:36 |
| wallyworld | good! | 04:36 |
| StevenK | Rargh | 04:36 |
| wallyworld | oh no, what? | 04:37 |
| StevenK | Damn it, auditor, stop failing on db-devel :-( | 04:37 |
| StevenK | Now wallyworld will yell at me again :-( | 04:37 |
| wallyworld | i didn't yell :-) | 04:37 |
| wallyworld | just asked politely | 04:37 |
| StevenK | I know, I'm teasing | 04:37 |
| wallyworld | irc is so devoid of emotional clues | 04:38 |
| StevenK | Hold on, I'll get in the car and drive 12 hours. Will that help? | 04:38 |
| wallyworld | ok, and bring cake | 04:39 |
| StevenK | You don't deserve any, due to being a large cake tease with spm. | 04:39 |
| wallyworld | i actually made one and sent him a picture :-D | 04:40 |
| wallyworld | it was sooo yummy too | 04:40 |
| StevenK | Yes, but he didn't get to eat any! | 04:40 |
| wallyworld | i know! hence the :-D | 04:40 |
| wallyworld | i was trolling him | 04:40 |
| StevenK | And then devel fails with test_getAllPermissions_constant_query_count | 04:48 |
| StevenK | Seriously | 04:48 |
| StevenK | This is why we can't have nice things. | 04:48 |
| wallyworld | i think the query count test was added relatively recently | 04:51 |
| StevenK | wgrant was talking about it yesterday | 04:52 |
| wallyworld | yeah, it's all soyuz fault | 04:53 |
| StevenK | wgrant: Terribly hard review up for you. https://code.launchpad.net/~stevenk/launchpad/clean-up-ibranch/+merge/121536 | 05:29 |
| StevenK | Oooh, Postgres 9.2 RC1 | 05:33 |
| stub | yeah, yeah. | 05:34 |
| StevenK | stub: Not a dig at you, just reading the blog post | 05:35 |
| stub | haha, yeah. Just don't get too excited :) | 05:35 |
| stub | 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 |
| StevenK | 'Fix bugs in pg_trgm' looks relevant too | 05:36 |
| StevenK | 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:03 |
| wallyworld | StevenK: sorry, was out buying dinner, looking now | 06:43 |
| wallyworld | 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 |
| wallyworld | i guess these will be killed next | 06:49 |
| wallyworld | r=me | 06:50 |
| StevenK | I thought that was dead | 06:50 |
| StevenK | ALTER TABLE Branch DROP COLUMN transitively_private; | 06:52 |
| StevenK | DROP TRIGGER maintain_branch_transitive_privacy_t ON Branch; | 06:52 |
| StevenK | DROP FUNCTION maintain_transitively_private(); | 06:52 |
| StevenK | In 16-6 | 06:52 |
| StevenK | steven@undermined:~/launchpad/lp-branches/clean-up-ibranch% grep -c maintain_transitively_private database/schema/security.cfg | 06:53 |
| StevenK | 0 | 06:53 |
| wallyworld | StevenK: in security.cfg, look for public.update_transitively_private(integer, integer, boolean) = | 07:23 |
| StevenK | With no perms | 07:29 |
| StevenK | But yeah | 07:30 |
| adeuring | good morning | 07:47 |
| === frankban changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: frankban | Firefighting: - | Critical bugs: 4.0*10^2 | ||
| jam | mgz: morning, /wave jelmer | 08:03 |
| jelmer | hello mgz, jam | 08:04 |
| jam | I'm technically off today, but I'd like to chat with you guys on mumble if you're available. | 08:04 |
| mgz | I'll hop on | 08:05 |
| === 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 | ||
| mgz | jelmer: so, I take it this is not the intended plan with the lucid/py27 ppa: <http://pastebin.ubuntu.com/1171529/> | 10:33 |
| jelmer | mgz: hehe, no | 10:34 |
| mgz | it also needs the normal launchpad ppas, and to upgrade everything? | 10:34 |
| mgz | or should just leave those packages alone? | 10:34 |
| jelmer | mgz: it should leave those packages alone | 10:35 |
| jelmer | mgz: are you looking at the bzr 2.5.1 upgrade, or should I ? | 10:36 |
| mgz | I can do that. | 10:37 |
| jelmer | 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 |
| maxb | 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:38 |
| * maxb has battle scars from backporting Python 2.7 to Debian etch. | 10:39 | |
| maxb | Yes, etc. | 10:39 |
| maxb | h | 10:39 |
| jelmer | maxb: that sounds painful | 10:40 |
| maxb | It was... interesting :-) | 10:40 |
| jelmer | mgz: why is that? | 10:40 |
| * mgz reads maxb's mind | 10:42 | |
| stub | So why aren't we just switching to Precise? The machines are all due for that upgrade anyway. | 10:43 |
| mgz | stub: this is what I keep asking. | 10:44 |
| mgz | 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:44 |
| mgz | but seems like it's just introducing yet another environment for things to potentially fail in. | 10:45 |
| stub | 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 |
| mgz | indeed. | 10:45 |
| stub | 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:46 |
| maxb | On a similar topic, why not precise/py26 rather than lucid/py27? | 10:51 |
| lifeless | we know that we're broken on 2.7 atm AFAIK. | 10:56 |
| lifeless | calling it tested for months is a massive exaggeration. | 10:56 |
| lifeless | maxb: because its a lot easier to rollback lucid/py27. | 10:57 |
| mgz | broken in non-testsuite ways? I'm reasonably sure I got all the test failures. | 10:57 |
| lifeless | yes | 10:58 |
| maxb | 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:58 |
| lifeless | maxb: we depend on very few system packages | 10:59 |
| maxb | hmm, ok, I was just looking at canonical-bazaar/py27 and noticing an awful lot of red Xes | 10:59 |
| stub | 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 | |
| lifeless | we had a disasterous time last time we did a lock step upgrade. | 11:01 |
| stub | 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 |
| lifeless | stub: how do you figure that ? | 11:03 |
| stub | 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 |
| lifeless | many devs develop on lucid in lxc; so nobody is an exaggeration. But sure. | 11:04 |
| lifeless | There are two separate transitions. | 11:04 |
| lifeless | There were three. | 11:05 |
| lifeless | postgresql | 11:06 |
| lifeless | python | 11:06 |
| lifeless | base os | 11:06 |
| lifeless | we did the same strategy for postgresql. | 11:07 |
| lifeless | and the associated libraries | 11:08 |
| lifeless | and we had small issues and friction | 11:08 |
| stub | postgresql is unrelated, as that is server migration. | 11:08 |
| lifeless | 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 |
| stub | We *want* things to fail under buildbot and staging. What we are worried about is production failures, and there is unrelated. | 11:09 |
| lifeless | if it was unrelated, we wouldn't have had to upgrade packages on all the production machines :) | 11:10 |
| stub | 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 |
| lifeless | they are *now* | 11:11 |
| lifeless | I'm not talking about precise on those servers | 11:11 |
| lifeless | I'm talking about 8.4->9.1 | 11:11 |
| lifeless | which was part of the overall upgrade-to-precise plan | 11:11 |
| adeuring | stub: thanks for the review | 11:23 |
| wgrant | stub: FYI in 9.1 we can now add constraints without too much downtime | 11:49 |
| wgrant | Using NOT VALID | 11:49 |
| wgrant | Then ALTER TABLE ... VALIDATE CONSTRAINT | 11:49 |
| wgrant | That may influence your opinion on adeuring's MP | 11:50 |
| stub | Oh, hadn't seen that. Ta. | 11:54 |
| lifeless | shiny | 11:54 |
| stub | Its only 100k rows to scan | 11:55 |
| wgrant | True | 11:56 |
| wgrant | But yeah | 11:56 |
| wgrant | that was a relatively late addition to 9.1 | 11:56 |
| wgrant | It was the last common really expensive operation | 11:56 |
| wgrant | that is now doable without major downtime | 11:56 |
| wgrant | makes me very happy | 11:56 |
| lifeless | 100k rows is probably too many | 11:59 |
| wgrant | Yeah | 12:00 |
| wgrant | Well | 12:00 |
| wgrant | It's only validation | 12:00 |
| wgrant | And it's pretty simple | 12:00 |
| wgrant | So it might be OK | 12:00 |
| wgrant | But I think you're still probably looking at >5s for that | 12:00 |
| wgrant | But I haven't thought that through properly | 12:00 |
| === gary_poster is now known as gary_poster|away | ||
| lifeless | I'm fairly sure we would be | 12:02 |
| lifeless | but data will tell | 12:02 |
| wgrant | I'd sort of expect 5-10s for a single node there | 12:02 |
| wgrant | but that's mostly a gut feeling | 12:03 |
| lifeless | I see progress from stub on rolling schema patches. | 12:03 |
| wgrant | oh? | 12:03 |
| lifeless | which will be awesome | 12:03 |
| wgrant | oh | 12:03 |
| wgrant | you mean nodowntimefastdowntime? | 12:03 |
| lifeless | nearlynodowntimefastdowntime | 12:03 |
| wgrant | right | 12:03 |
| wgrant | noreaddowntime | 12:03 |
| wgrant | yeah | 12:03 |
| wgrant | we discussed that last night | 12:03 |
| lifeless | great. | 12:03 |
| wgrant | i saw a branch | 12:03 |
| wgrant | looks ok | 12:04 |
| lifeless | I should spend more time not looking in the channel, you guys get up to good stuff :) | 12:04 |
| wgrant | it will be marvellous :) | 12:04 |
| lifeless | stub: sorry I didn't catch up w/ you last week, was -hectic-. | 12:04 |
| lifeless | stub: this week may be too, for different reasons. | 12:04 |
| StevenK | And in Sydney | 12:04 |
| lifeless | stub: if you want to catch up, wed is probably the day, or we can raincheck it - whatever you prefer | 12:04 |
| lifeless | *yawn*, ciao. | 12:05 |
| stub | lifeless: whatever :) | 12:05 |
| stub | see how we go tomorrow | 12:06 |
| wgrant | Night lifeless | 12:06 |
| stub | and from above, just about to push the tests. | 12:08 |
| === gary_poster|away is now known as gary_poster | ||
| wgrant | stub: yeah, i'm glad we have pgbouncer fixtures working so we can actually test that excellently | 12:11 |
| wgrant | this is not the sort of stuff we want untested | 12:11 |
| czajkowski | mgz: you about? | 12:31 |
| mgz | yup | 12:35 |
| mgz | will need some lunch shortly though. | 12:36 |
| czajkowski | 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 <Launchpad itself:New> < https://launchpad.net/bugs/1042351 > | 12:36 |
| czajkowski | else I'll poke jelmer when he gets back | 12:36 |
| mgz | it's an old format, which may upset things, otherwise need to look at logs/code for more info | 12:41 |
| === al-maisan is now known as almaisan-away | ||
| rick_h_ | abentley: let me know if there's anything I can do to help ease the JS pain in that stuff. | 13:48 |
| abentley | rick_h_: Thanks. | 13:48 |
| === 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 | ||
| jcsackett | anyone know how up to date the data on staging is? | 19:29 |
| abentley | rick_h_: Could you please review this? https://code.launchpad.net/~abentley/launchpad/blueprint-info-type-code/+merge/121683 | 19:42 |
| rick_h_ | abentley: sure thing | 19:47 |
| === cr3_ is now known as cr3 | ||
| === cr3 is now known as Guest4554 | ||
| rick_h_ | abentley: is the diff off or are the other changed files just part of a merge conflict resolve business? | 19:54 |
| abentley | rick_h_: The changed files listed in the lint? | 19:54 |
| rick_h_ | yea, there's many more files as 'changed' but only the one small diff in specification.py | 19:54 |
| rick_h_ | the patch, garbo, etc | 19:55 |
| abentley | rick_h_: The lint is stale. | 19:55 |
| abentley | rick_h_: It's from before abel duplicated my work. | 19:55 |
| rick_h_ | ok cool, just wanted to make sure I wasn't missing things | 19:55 |
| rick_h_ | abentley: ok r=me | 19:55 |
| === rick_h_ changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: 4.0*10^2 | ||
| lifeless | o/ | 20:08 |
| jelmer_ | g'morning lifeless | 20:08 |
| abentley | rick_h_: I think I've got an improvement on the JS_YUI rule: http://pastebin.ubuntu.com/1172484/ | 20:24 |
| abentley | lifeless: Hi. Can you help me with the DB patch for indexing Specification.information_type ? | 20:27 |
| lifeless | abentley: sure thing, how can I help? | 20:37 |
| abentley | lifeless: First thing, I didn't test it on qastaging. Is that essential? | 20:37 |
| lifeless | the risk of not testing it is that it triggers poor queries for the table | 20:38 |
| lifeless | we wouldn't expect a hot patch to fail to apply (as long as its not adding uniqueness that is) | 20:38 |
| abentley | lifeless: Since this column is not used anywhere, I don't think there's a risk of that. | 20:39 |
| lifeless | abentley: its a single column index? | 20:39 |
| abentley | lifeless: Yes. | 20:39 |
| lifeless | I agree. | 20:40 |
| abentley | lifeless: It is r15850. I can put up a deploy request. | 20:41 |
| lifeless | hot patches are still done by stub | 20:41 |
| lifeless | so the best thing is to email him and ask for it to be applied | 20:42 |
| abentley | lifeless: it says TA does them here: https://wiki.canonical.com/Launchpad/PolicyandProcess/ProductionChange | 20:42 |
| lifeless | I can if it's urgent, but the production environment right now is in a great deal of flux | 20:43 |
| === Guest4554 is now known as cr3 | ||
| lifeless | we're running on temporary servers, have just migrated off of slony etc. | 20:43 |
| === cr3 is now known as Guest86189 | ||
| lifeless | I'd rather avoid fragmenting the state about where we are at by applying it myself, until we're back to normal. | 20:44 |
| abentley | lifeless: Okay, just wanted you to know. If the info's incorrect, we should change it, but it sounds like it's just temporary. | 20:44 |
| lifeless | Getting stuart to do it will add ~8 hours delay - he's asleep at the moment. | 20:44 |
| lifeless | It is,. | 20:45 |
| lifeless | abentley: so, you'll email stub? Or would you like me to? | 20:50 |
| abentley | lifeless: I've emailed him. Thanks. | 20:50 |
| lifeless | Cool, de nada. | 20:50 |
| lifeless | http://lipka.github.com/piecon | 21:57 |
| wgrant | lifeless: Can we convince ops to do hot patches now that slony's gone, or are we still blocking on them not have to transform them to CONCURRENTLY manually? | 23:24 |
| lifeless | wgrant: its a good question, I was considering this earlier. | 23:25 |
| lifeless | There were two complexities - per-node + concurrently transform. | 23:25 |
| lifeless | We've halved that. | 23:25 |
| wgrant | Right | 23:26 |
| lifeless | I would like to switch us to lazr-postgresql's patch applier now. | 23:26 |
| lifeless | Which understands this more or less. | 23:26 |
| lifeless | So it wouldn't need special handling. | 23:26 |
| lifeless | That would make the ops discussion real easy. | 23:26 |
| wgrant | ops certainly seem to be a lot more comfortable with manual stuff like grants now that it only has to be done on a single node | 23:26 |
| lifeless | just needs it glued into the FDT scripts. | 23:27 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!