[01:22] <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:23] <wallyworld> lol
[01:23] <wallyworld> that sort of thing happens to me too
[01:58] <StevenK> wallyworld, wgrant: https://code.launchpad.net/~stevenk/launchpad/drop-disclosure-feature-flags/+merge/121523
[01:58] <wgrant> +271? :(
[01:59] <wallyworld> what did you expect? it's a net loss of code
[02:00] <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:01] <wgrant> :(
[02:05] <wgrant> StevenK: I don't quite understand what's going on in bugsubscription.txt
[02:05] <wgrant> Is there some broken unsubscription logic?
[02:06] <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:07] <wallyworld> thanks
[02:08] <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:10] <wgrant> Oh hm
[02:10] <wgrant> No, that doesn't explain it
[02:18] <StevenK> wgrant: I tried to explain it in the MP description.
[02:19] <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:20] <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:21] <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:22] <wgrant> Oh, right
[02:23] <wgrant> Makes sense, then
[02:23] <wgrant> But please do dispose of enhanced_picker fully
[02:24] <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:30] <rick_h_> wallyworld: tossed a side note out to your MP
[02:30]  * wallyworld looks
[02:31] <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:32] <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:33] <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:35] <wallyworld> rick_h_: the banner etc is currently expected to be there since it makes direct calls to the various methods
[02:36] <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:37] <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:38] <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:39] <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:40] <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:41] <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:42] <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:44] <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:45] <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:46] <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:52] <wgrant> wallyworld: Oh right, we can use set literals now, can't we...
[02:52] <wallyworld> yeah
[02:53] <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:54] <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:55] <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:56] <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:57] <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:58] <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:59] <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?
[03:00] <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:01] <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:02] <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:03] <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:04] <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:05] <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:06] <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:07] <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:08] <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:09] <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:10] <wallyworld> especially with html forms for the exact same editing operation is use
[03:10] <wallyworld> we want to keep the code common
[03:12] <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:13] <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:14] <wgrant> Indeed
[03:14] <wallyworld> and then the issue would be moot
[03:18] <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:19] <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:20] <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:21] <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:22] <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:42] <wgrant> StevenK: Hah
[03:42] <wgrant> StevenK: I just tripped over the makeBug(product=) thing myself
[03:50] <StevenK> Hahaha
[03:53] <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:54] <wallyworld> hope i haven't missed anything
[03:54] <wgrant> Nope, r=me
[03:54] <wgrant> Thanks
[03:54] <wallyworld> coo :-)
[03:55] <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:58] <StevenK> wgrant: Your comment on the MP pre-dates our discussion about bugsubscription.txt?
[03:59] <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/
[04:00] <StevenK> wallyworld: Opinions, have I missed something/looks okay?
[04:00]  * wallyworld looks
[04:06] <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:07] <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:08] <wallyworld> should be            show_create_team=self.show_create_team)
[04:09] <StevenK> Hmmm, I think show_create_team_link in that class can die too
[04:10] <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:11] <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:12] <wallyworld> looks ok otherwise, but do run it up locally and test project creation and editing of owwner/driver
[04:13] <StevenK> wallyworld: Not sure which tests can die, but http://pastebin.ubuntu.com/1171125/
[04:15] <wallyworld> StevenK: i'm not sure either, ignore that dumb comment of mine. i think it looks ok
[04:27] <wallyworld> wgrant: distributions don't have bug/branch sharing policies yet, right?
[04:33] <StevenK> wallyworld: I just tried New Team. It looks *awesome*
[04:34] <wallyworld> StevenK: oh, cool, ta :-)
[04:34] <StevenK> wallyworld: It needed to be 'show_create_team=self.show_create_team_link' anyway
[04:35] <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:36] <StevenK> wallyworld: Yeah, I tried assigning a bug and there was no create team link
[04:36] <wallyworld> good!
[04:36] <StevenK> Rargh
[04:37] <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:38] <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:39] <wallyworld> ok, and bring cake
[04:39] <StevenK> You don't deserve any, due to being a large cake tease with spm.
[04:40] <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:48] <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:51] <wallyworld> i think the query count test was added relatively recently
[04:52] <StevenK> wgrant was talking about it yesterday
[04:53] <wallyworld> yeah, it's all soyuz fault
[05:29] <StevenK> wgrant: Terribly hard review up for you. https://code.launchpad.net/~stevenk/launchpad/clean-up-ibranch/+merge/121536
[05:33] <StevenK> Oooh, Postgres 9.2 RC1
[05:34] <stub> yeah, yeah.
[05:35] <StevenK> stub: Not a dig at you, just reading the blog post
[05:35] <stub> haha, yeah. Just don't get too excited :)
[05:36] <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
[06:03] <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:43] <wallyworld> StevenK: sorry, was out buying dinner, looking now
[06:49] <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:50] <wallyworld> r=me
[06:50] <StevenK> I thought that was dead
[06:52] <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:53] <StevenK> steven@undermined:~/launchpad/lp-branches/clean-up-ibranch% grep -c maintain_transitively_private database/schema/security.cfg
[06:53] <StevenK> 0
[07:23] <wallyworld> StevenK: in security.cfg, look for public.update_transitively_private(integer, integer, boolean) =
[07:29] <StevenK> With no perms
[07:30] <StevenK> But yeah
[07:47] <adeuring> good morning
[08:03] <jam> mgz: morning, /wave jelmer
[08:04] <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:05] <mgz> I'll hop on
[10:33] <mgz> jelmer: so, I take it this is not the intended plan with the lucid/py27 ppa: <http://pastebin.ubuntu.com/1171529/>
[10:34] <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:35] <jelmer> mgz: it should leave those packages alone
[10:36] <jelmer> mgz: are you looking at the bzr 2.5.1 upgrade, or should I ?
[10:37] <mgz> I can do that.
[10:38] <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:39]  * maxb has battle scars from backporting Python 2.7 to Debian etch.
[10:39] <maxb> Yes, etc.
[10:39] <maxb> h
[10:40] <jelmer> maxb: that sounds painful
[10:40] <maxb> It was... interesting :-)
[10:40] <jelmer> mgz: why is that?
[10:42]  * mgz reads maxb's mind
[10:43] <stub> So why aren't we just switching to Precise? The machines are all due for that upgrade anyway.
[10:44] <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:45] <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:46] <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:51] <maxb> On a similar topic, why not precise/py26 rather than lucid/py27?
[10:56] <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:57] <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:58] <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:59] <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
[11:01] <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:03] <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:04] <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:05] <lifeless> There were three.
[11:06] <lifeless> postgresql
[11:06] <lifeless> python
[11:06] <lifeless> base os
[11:07] <lifeless> we did the same strategy for postgresql.
[11:08] <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:09] <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:10] <lifeless> if it was unrelated, we wouldn't have had to upgrade packages on all the production machines :)
[11:11] <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:23] <adeuring> stub: thanks for the review
[11:49] <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:50] <wgrant> That may influence your opinion on adeuring's MP
[11:54] <stub> Oh, hadn't seen that. Ta.
[11:54] <lifeless> shiny
[11:55] <stub> Its only 100k rows to scan
[11:56] <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:59] <lifeless> 100k rows is probably too many
[12:00] <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:02] <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:03] <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:04] <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:05] <lifeless> *yawn*, ciao.
[12:05] <stub> lifeless: whatever :)
[12:06] <stub> see how we go tomorrow
[12:06] <wgrant> Night lifeless
[12:08] <stub> and from above, just about to push the tests.
[12:11] <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:31] <czajkowski> mgz: you about?
[12:35] <mgz> yup
[12:36] <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:41] <mgz> it's an old format, which may upset things, otherwise need to look at logs/code for more info
[13:48] <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.
[19:29] <jcsackett> anyone know how up to date the data on staging is?
[19:42] <abentley> rick_h_: Could you please review this? https://code.launchpad.net/~abentley/launchpad/blueprint-info-type-code/+merge/121683
[19:47] <rick_h_> abentley: sure thing
[19:54] <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:55] <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
[20:08] <lifeless> o/
[20:08] <jelmer_> g'morning lifeless
[20:24] <abentley> rick_h_: I think I've got an improvement on the JS_YUI rule: http://pastebin.ubuntu.com/1172484/
[20:27] <abentley> lifeless: Hi.  Can you help me with the DB patch for indexing Specification.information_type ?
[20:37] <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:38] <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:39] <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:40] <lifeless> I agree.
[20:41] <abentley> lifeless: It is r15850.  I can put up a deploy request.
[20:41] <lifeless> hot patches are still done by stub
[20:42] <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:43] <lifeless> I can if it's urgent, but the production environment right now is in a great deal of flux
[20:43] <lifeless> we're running on temporary servers, have just migrated off of slony etc.
[20:44] <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:45] <lifeless> It is,.
[20:50] <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.
[21:57] <lifeless> http://lipka.github.com/piecon
[23:24] <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:25] <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:26] <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:27] <lifeless> just needs it glued into the FDT scripts.