=== wgrant_ is now known as wgrant
cjwatsonlifeless: OK, I'll just roll it into the code change corresponding to that db change, then00:10
=== jtv1 is now known as jtv
StevenKTest failures due to a DB patch can be fixed in the DB branch, or should be landed first?02:24
lifelessland first if at all possible02:25
lifelessas we can't make code changes when the DB patch deploys, we want to be sure things will be ok when it deploys02:25
lifeless(and land on devel of course)02:25
wgrantStevenK: What's the issue?02:26
StevenKwgrant: test_branch_privacy_triggers does manual INSERTs into Branch which blows up when it's NOT NULL.02:26
StevenKWhen information_type is set NOT NULL, sorry.02:27
wgrantEven if it's just test changes, I'd still do it in devel.02:27
wgrantIf it's not just test changes, it has no choice but to go to devel.02:28
StevenKYes, I'm putting together a branch now02:28
wallyworld_wgrant: i've done a branch behind a feature flag to revoke bug access on unsubscribe but of course the triggers do that and so the test fails. one option is to have the test remove the trigger. any other ideas?02:37
StevenKwgrant: https://code.launchpad.net/~stevenk/launchpad/information_type-branch-privacy-trigger/+merge/10529102:38
lifelesswallyworld_: wait, what? Do you mean unsubscribe after bug access is revoked?02:39
wallyworld_lifeless: no. other way around. we already have a job to unsubscribe after access is revoked02:40
wgrantlifeless: Someone hasn't been reading launchpad-dev :)02:40
lifelesswgrant: thread name ?02:43
wgrant[Launchpad-dev] Next steps for Better Privacy02:43
lifelesswallyworld_: you should be able to unsubscribe and retain access in the new world order, surely ?02:43
wgrantlifeless: This is the Transitional World Order02:43
wallyworld_lifeless: eventually yes02:43
wgrantNot yet New World Order02:43
wgrantMore specifically, this is the Transitional While We Have No UI Design But Need To Sort The Model Out World Order02:44
wallyworld_lifeless: we initially want to mimic current behaviour02:44
lifelesswgrant: I have no such email02:44
StevenKlifeless: When did you unsubscribe from -dev? :-P02:45
lifelessStevenK: probably when I subscribed to a different list; +editemails is error prone02:45
wallyworld_wgrant: i could also make the trigger look at the feature flag table. i think that's the best option02:45
lifelessyup, there we go02:45
lifelessno wonder it was quiet02:46
wgrantwallyworld_: Ew02:46
wallyworld_why ew?02:46
StevenKlifeless: Would you like me to forward it?02:46
wgrantwallyworld_: It's unprecedented and there must be a better way02:46
lifelessI'm reading the list archives02:47
wallyworld_what is wrong with business logic checking feature flags?02:47
wgrantwallyworld_: It's a second implementation of the feature flag logic.02:47
wallyworld_shouldn't matter that the business logic is in a trigger02:47
wgrantThis time in PL/pgSQL02:47
StevenKwallyworld_: The flag table contains a scope. How are you going to get a trigger to work THAT out?02:47
wallyworld_the only other way that i can see is to have the test disable the tirgger02:47
StevenKAs wgrant says, Ew.02:47
wallyworld_detail, details02:48
wallyworld_forgot about the scope02:48
wallyworld_but i was thinking this would be on or off for all02:48
wgrantRight, scope is the main problem.02:48
wgrantYou could just always use 'default';02:48
wallyworld_so could ignore scope02:48
StevenKIf you implement flag scoping in PL/pgSQL, wgrant may murder you.02:48
wgrantBut it's still a bit ew, which is why I'm trying to think of a better way02:49
wallyworld_so i could just ignore scope is what i was thinking02:49
wgrantwallyworld_: This is the test for when the flag is disabled?02:49
lifelessso I can see this transition02:49
lifelessI have two thoughts02:49
lifelessfirstly, have you considered just doing the final thing, directly.02:49
wgrantlifeless: I was surprised when you didn't reply.02:50
wgrantlifeless: I guess this explains it :)02:50
wallyworld_wgrant: yes02:50
wgrantlifeless: I guess checking the flag, explicitly in the 'default' scope, might be best. Otherwise removing the trigger later without illegally hacking tests might be awkward.02:51
lifelesswgrant: so, AIUI the remove-grants-on-removed-subscriptions is being written to cope with...02:51
lifeless'there is no UI for showing who has access but not a subscription'02:51
lifelessso if you wrote that UI today (and define it as crudely as possible - e.g. just show 'everyone with access')02:52
lifelessyou wouldn't need a job to remove access when a subscription is removed02:53
wallyworld_it wouldn't be a job02:53
wallyworld_but yes02:53
lifelessjob task code function helper etc02:53
wgrantlifeless: Sure.02:53
wallyworld_i was being a pedant :-P02:53
lifelesswallyworld_: orly ? :)02:53
wgrantlifeless: But the UI would be very duplicatastic with the subscriber list, and we would have to introduce a whole lot of new sharing management widgets on the bug page.02:54
lifelesswgrant: so, you're not doing htat.. why not ?02:54
wgrantNone of which we have design for, and all our UI people are off doing other things.02:54
lifelessare you planning on doing that anyway ?02:54
wgrantMostly MAAS02:54
lifelesswe don't have to get the presentation perfect first time around02:54
wgrantWe have to have it not be utter shit.02:55
lifelessthe key elements of design in this are already committed too - this is just the ramifications02:55
wgrantAnd it has to not be confusing.02:55
wgrantBecause this involves privacy.02:55
lifelessI agree.02:55
wgrantSo, we can implement this transitional thing in the next roughly two weeks.02:55
lifelessis there a page showing who can see a given bug, today ?02:55
wgrantWe cannot get design tested before then.02:55
wgrantlifeless: The subscriber list.02:55
wallyworld_lifeless: wgrant: should we move the subscribers portlet off the default bugtask view and replace with 'who has access'?02:55
wallyworld_that makes more sense to me02:56
wgrantwallyworld_: That's for UI people and testing to answer :)02:56
wallyworld_since i want to know who can see my stuff02:56
wgrantWe'll be lucky to get an hour of UI time this month.02:56
lifelesswallyworld_: we could; some folk want to know who will be notified. Arguably the contents of both portlets should be expandable.02:56
wallyworld_and till now, who can see = who is subscribed02:56
lifelessone way would be to expand the subscribers portlet02:56
lifelessit currently says 'you get xxx, these people get xxx, these people may get xxx', adding 'these other people are able to view the bug but do not get xxx'02:57
wallyworld_we would need to use expanders i think if we do that, but could be ok02:57
lifelesswould make a lot of sense to me02:57
lifelessit would be totally empty for a bug today.02:57
wgrantlifeless: The transitional phase lets us add a single simple extra bit of UI (the policy grantee list) and a couple of extra model bits, and it lets us sort of the model so the new UI can be implemented easily once it's designed.02:57
lifelessand if its the same portlet, there is ~= no perf overhead.02:57
wgrants/sort of/sort out/02:58
lifelessw.r.t. removing the triggers, my suggestion would be:02:58
lifeless - have tests that use a feature flag to indicate whether the triggers exist or not.02:58
lifelessand have a DB patch that removes the triggers and sets the feature flag ob.02:58
lifelesss/tests that use.../code that uses.../02:58
wgrantThat's a possibility.02:58
lifelessa small test fixture to give you no triggers + feature rule, will let you write tests now02:59
lifelessyou won't be able to go live except in a foul swoop, so you'd want to tightly limit how much code lived under that flag.02:59
lifeless(OTOH we could rollback relatively easily)02:59
wallyworld_lifeless: you mean the fixturewould disable the triggers in its setup? and enable after?03:00
wgrantFoul swoop? :)03:00
wgrantSounds reasonable, though.03:00
lifelesswallyworld_: yeah.03:00
lifelessideally you'd write code that doesn't care about the triggers or not.03:00
lifelessWhich is why I am also questioning why you're doing that.03:00
wallyworld_lifeless: i was thinking the same thing when i initially posed this issue above03:00
lifelessThe lack of design-team seems like a poor reason not to use your own judgement03:01
wallyworld_lifeless: well the code is to replace the trigger eventually03:01
wallyworld_i think it better that the ui be done so the triggers can be removed03:01
lifelessdo something tolerable and quick (show them at the end of the subscribers list), and revisit when design have bandwidth.03:01
wgrantlifeless: It's not just showing them.03:01
wgrantlifeless: We have to be able to remove them and possibly add them too...03:02
lifelesswgrant: with a (-) button to remove them.03:02
wgrantThat's why showing policy grants is light.03:02
wgrantBecause you can't remove them from that page.03:02
wallyworld_wgrant: that's what the +sharing page is for03:02
wgrantlifeless: Who has permission to remove them?03:02
wallyworld_or not?03:02
wgrantwallyworld_: You really need to be able to revoke from both ends.03:02
wallyworld_not   initially03:02
wgrantwallyworld_: Particularly since only the project owner can remove people on +sharing03:02
lifelesslets separate out needed and wanted03:02
wgrantThis is needed.03:02
wallyworld_we could just do read only portlet on bugtask page03:03
wgrantWe can't block on the CC to remove people from bugs...03:03
lifelesswgrant: wallyworld_ is not suggesting that03:03
wallyworld_be we can remoe people via the sharing page03:03
wgrantwallyworld_: Only the pillar owner can use +sharing03:03
lifelessah yeah03:03
wallyworld_sure, so?03:03
lifelesswgrant: so, you can add (-) with the same rules from removing subscriptions, initially.03:03
lifelesswgrant: that is clearly ok, because it works for subscriptions.03:04
wallyworld_why should anyone besides the pillar owner be able to revoke access?03:04
wgrantI can see danhg and huwshimi coming to strangle us in our sleep, though.03:04
lifelesswgrant: you could broaden it to allow the pillar owner to always remove, to be in line with +sharing.03:04
wallyworld_regardless of if it's done from bugtask or +sharing03:04
wgrantwallyworld_: I've filed a bug containing user data that's private to me.03:04
wgrantwallyworld_: But I can't prevent people from accessing it, because Launchpad is stupid :(03:04
lifelesswgrant: on what basis? That you did /something/, with communication with them about what you're doing (to give them the opportunity to go nononnonoon if needed), and behind a ff, so that its got no UI impact until you're happy with it?03:05
wallyworld_ok so we can allow bug owner + pillar owner03:05
wgrantlifeless: Anyway03:05
lifelesswallyworld_: there is no 'bug owner' :P03:05
wgrantI still think we should do what I proposed.03:05
wgrantIt's one little workaround to remove grants on unsubscriptions03:05
wgrantAnd preserves the current UI03:05
lifelesswgrant: its up to you guys as a group, you're doing the work.03:05
wallyworld_bug task owner(s) i think i meant03:05
lifelessmyself, I always try to go as directly as possible.03:06
lifelessI don't see preserving the current UI as a goal, at any stage.03:06
wallyworld_in this case i'm +1 with lifeless03:06
wgrantEvolving the privacy rules gradually is a recipe for disaster.03:07
wallyworld_especially if it's behind a flag03:07
wgrantwallyworld_: It can't be behind a feature flag.03:07
wgrantNot completely.03:07
wallyworld_the ui i mean03:07
wgrantIt has to be shown to everyone the moment anyone can edit grants directly.03:07
wallyworld_and then when we are happy with it, we can remove the triggers to revoke on unsubscribe03:08
wgrantOr access becomes opaque03:08
lifelessso what wgrant means, I think, is that when 'add without subscription' becomes available to *anyone*, then that access can't be hidden by the ff03:08
lifelessso the change to the subscriber portlet, while it can be ff'd to start with03:08
lifelesshas to go live as soon as any manual grant - pillar or artifact scoped - is addable to the system03:08
wgrantSo we cannot do gradual rollout.03:09
wallyworld_so long as the portlet looks ok, what's the issue?03:09
lifelessbut again, this is a tiny, shallow UI change, consistent with current layout, and if we're committing to reviewing it to fix issues huwshimi/dan/mrevell identify, I don't see the issue.03:09
lifelessyou don't need it globally visible *until* you FF enable the 'add manual grant' feature03:09
lifelessand that feature, is one that you don't need to enable until very late in the piece.03:10
lifelessfolk may want it sooner, but its up to you when its delivered.03:10
lifelessSo you can have as much design/UI review as you like before flipping the switch.03:10
lifelessYou can gradual-rollout the new subscriber portlet info in advance of gradual-rollout the ability to add grants03:11
lifelesstotally doable.03:11
wgrantAnd totally another two weeks.03:11
wallyworld_if we roll out the new ui, it will always be empty anyway atm due to the triggers03:12
wgrantIndeed, the new section of the porlet will not be seen until manual grants happen.03:12
wgrantSo a gradual rollout there is not useful.03:12
lifelessless useful03:13
lifelesstotally unuseful? don't think so. Missing table perms etc would be caught03:13
lifelesspoor query performance likewise.03:14
lifelesswgrant: why another two weeks?03:14
wgrantlifeless: Because that's how Launchpad works.03:14
wallyworld_and i could hack in data for a screenshot03:14
lifelessI can't usefully comment on such hyperbole03:14
wgrantIt's not hyperbole.03:14
wgrantAttempting to iterate on interlocked UI and model changes *does not work*.03:15
wgrantIn Launchpad.03:15
lifelesswhat model changes are expected here?03:15
lifelessother than the trigger discard03:15
wallyworld_wgrant: i call bullshit on that one. i did it fine for the +sharing page03:15
wgrantlifeless: Moving access management into the application and out of the database, for one.03:16
wallyworld_lifeless: we will only likely one one additional service method on the sharing service03:16
wallyworld_for me to do the ui03:16
lifelesswgrant: how is that different to the trigger being discarded?03:16
wgrantwallyworld_: Permissions are going to be very awkward, but we'll see.03:16
wallyworld_permissions for editing maybe03:16
wallyworld_but that's a separate issue03:17
wallyworld_the ui can still be done incrementally, first read only, the editable03:17
wallyworld_and feedback can still be gotten03:17
wgrantI am very wary about gradually evolving the privacy UI like that.03:17
wgrantIt's going to confuse people, and everyone already makes enough mistakes.03:18
wallyworld_confuse who?03:18
wallyworld_it will only be visible to select people03:18
wallyworld_us and product team perhaps03:18
wgrantSure, but we have to eventually roll this transitional edit UI out to everyone.03:18
wgrantOnly to change it again later.03:18
wallyworld_or we could deploy it in one go like we said above03:19
lifelesswe change UI all the time, after we have data about how well it works.03:19
wgrantwallyworld_: This UI we've discussed here won't be the final one.03:19
lifelesswgrant: why not ?03:19
lifelesswell, let me rephase03:19
lifelessbeyond design requested changes03:19
lifelesswhich isn't a guaranteed thing, because you might be doing it well enough first pass.03:20
wgrant... because there will be design requested changes.03:20
wallyworld_so? we have to start somewhgere03:20
wallyworld_and so long as it's functional and not too ugly03:20
wallyworld_then it will be fine surely03:20
lifelessretitle 'subscribers portlet' to 'sharing and notifications' - |your status | other people with different sorts of status| status2 | status3\03:20
lifeless(rotated 90'03:20
wgrantwallyworld_: I can see the blog post now03:21
lifeless'LP developers delivered on time' ?03:21
wgrant"Now, there are some people that have access but aren't subscribed. You can't add them, and they'll only appear sometimes, when something has happened. In a week this will change and everything will be like this"03:21
wallyworld_that's not very helpful. i don't think it will happen like that at all03:22
lifelessSo, keep your current job :)03:22
lifelessI don't think marketing is your forte.03:22
lifelesshmm, that sounded meaner than I meant it. Sorry.03:22
lifelessBut seriously, I would say something like this:03:23
lifeless'The disclosure project has now enabled direct access control for the beta users of Launchpad. Users of that team can now grant access to private and security bugs without needing to create subscriptions. Less mail!.03:24
wgrantSo now we need the grant access UI too!03:24
wallyworld_hmm. if only there were someone around who could write code03:25
wgrantCode isn't the problem.03:25
wgrantCode is easy.03:25
lifeless*All users* of Launchpad will be able to see who has been granted access to a private or security bug. Once we've shaken down the system with our beta team, we will permit all users to use this facility."03:25
wgrantUI when all our UI people have been stolen is the problem.03:25
lifelesswgrant: hangon, take a step back please.03:25
lifelessand a good long breath.03:25
wgrantWe won't be allowed to do this without mockups and user testing, and that will take at least 6 weeks.03:26
lifelessMy understanding is that noone will know this change is around until the grant access UI is enabled.03:26
lifelessTrue or False.03:26
wgrantThe sharing management UI in general, yes/03:26
lifelessSo True.03:26
lifelessAnd, thats feature flagged.03:26
lifelessSo, there is no need for the blog until that flag is toggled.03:27
lifelessAnd the sketch I gave for a blog is sufficient when the flag is toggled - if the 'grant access' UI is the sharing management UI, thats sufficient.03:27
wgrantWe this still means we can't finish the model until the new UI is designed.03:28
lifelessso why did you wax sarcastic?03:28
lifelesswgrant: so do the design for the UI.03:28
wgrantHave you ever designed UI using the new process?03:28
lifelessThere is a difference between design and signoff.03:28
wallyworld_we don't need the entire process to get started03:28
wallyworld_or to have enough to do the model03:28
wgrantWe do.03:28
lifelessI feel like you have a genuine point somewhere, but its getting hidden behind absolute statements and general hysteria.03:29
lifelessThis is exhausting trying to work through.03:29
wgrantWe cannot evolve the model until the UI enforces its display limitations.03:29
wallyworld_sigh. i'm going to write code. see y'all03:29
wgrantThe point of my plan is to allow us to evolve the model before we have UI03:29
wgrantIn lifeless' plan, we cannot evolve the model until the new UI is turned on.03:29
wgrantWhich requires signoff.03:29
wgrantturned on for everyone, that is03:29
lifelessYour plan requires that where the model is implemented move around, but htat the model (in the general sense of 'rules of the system') stay the same for the same period of time.03:30
wgrantCrucially, it allows us to completely stabilise the model code and work on more project privacy.03:31
lifelessI was hoping to unblock you on a technically hairy transition, but if you believe you can't do it differently, thats your call. I'm not here to tell you how to do it.03:31
wgrantMeanwhile the UI can be bikeshedded without blocking the rest of the world.03:31
lifelessWhat I would do is nab dan or huw on skype tomorrow, talk them through the key things (show the non-subscribed grants, show a (-) if you can remove them), get them to ack that as a provisional thing, and move on.03:33
lifelessLP UI will be bikeshedded for the next 50 years03:33
lifeless(thats hyperbole :P)03:33
cody-somervilleYea. We'll be using github by then.03:37
* cody-somerville ducks.03:37
StevenKwgrant: Does any of the bugsearch stuff still reference Bug.private ?04:28
wgrantStevenK: Not the main stuff, but there are some stragglers.04:32
wgrantMost were eliminated in a branch that landed a few hours ago.04:33
StevenKwgrant: So we can't quite rip out Bug._private and friends yet04:33
wgrantSadly not.04:33
StevenKDo you think it's worth putting together a silly branch that drops them just to see how much fallout is involved, or not yet?04:34
wgrantNot yet.04:34
* StevenK will continue to bash his head against IBranch.04:35
wgrantNot until the legacy half of get_bug_privacy_filter is gone and we've grepped for [Bb]ug.private04:35
StevenKjtv: O HAI04:35
StevenKwgrant: Bug.private isn't dying, ._private is.04:35
wgrantI mean DB [Bb]ug.private04:36
StevenKHm, I think Bug._private might actually be dead.04:37
wgrantI believe it was meant to be unused except for compatibility with DB queries.04:41
StevenKRight. I just can't see any others in the tree.04:42
* StevenK reads the triggers related to Branch.transitively_private and prepares for a 12 hour drive.04:58
StevenKwgrant: Hm, you were involved with jtv's testing on staging, does that qualify as QA for the purposes of r15218 and r15220 ?05:13
wgrantStevenK: No, there have been some slight changes since.05:14
wgrantHe might be able to judge it sufficient, but I don't particularly want to.05:15
StevenKwgrant: Yah, okay05:15
lifelessczajkowski: I thought you were @ UDS ?05:56
czajkowskilifeless: yup I am indeed05:58
czajkowskilifeless: and I work on lp stuff in and around sessions and stuff so working now for a bit05:58
czajkowskibut need jtv :/05:58
lifelessczajkowski: isn't it 11pm ?06:00
czajkowskilifeless: yup06:00
jtvStevenK: no, it's not quite the same thing.  I've been trying to Q/A, but running into qastaging trouble06:08
lifelessczajkowski: btw, feature work defects are never critical, unless they are oopsing06:12
lifelessczajkowski: (because its planned work, its not an interrupt)06:12
czajkowskilifeless: ah ok thought they were as they're part of a new feature not working as the feature intended06:12
lifelessczajkowski: no worries; also minor things like typo are at most high06:13
lifeless(they don't stop people getting their work done)06:13
lifelessczajkowski: 997346 should indeed be critical, because its a regression - but it should have the tag added06:14
lifelessczajkowski: there is I think (and if not there should be), in the bug triage wiki docs a comment to the effect of 'all critical bugs have to have a tag explaining why'06:15
lifelesse.g. timeout, or oops, or escalated, or regression06:15
lifelessmmm, and looking closer06:16
lifelessstub: hi thar06:19
lifelessgood morning :P06:20
lifelessstub: ready for a catch up?06:21
stubHa. Can do, but not ready :)06:23
lifelessskype or g+ ?06:24
stubHang on, need to steal my mike back.06:25
stubI still haven't tried G+.06:26
lifelessskype then :)06:26
wallyworld_stub: hi. for some tests, is there an 'admin' user i can use like "with dbuser('admin')" which allows me to avoid 'you do not own this relation' errors. i have got it to work with 'ian' but obviously i can't commit that07:23
stubwallyworld_: There is a 'testadmin' user07:24
wallyworld_stub: it still complains when i try that07:24
stubHmm... 'you do not own this relation'. What are you trying to do?07:24
wallyworld_stub: disable a trigger07:24
stuboic. Need to be the real owner then.07:25
wallyworld_as in 'ian' or whoever?07:25
* stub checks to confirm if 'launchpad' or other07:25
stubwallyworld_: os.environ['USER'] would be best for now07:26
wallyworld_stub: cool. thanks07:26
stubwallyworld_: Ideally, the 'testadmin' user should be a superuser if we are trying to do this sort of thing. Open a bug if you like.07:26
wallyworld_stub: will do. i was hoping there'd be a symbolic admin user i could use07:27
stubCurrently it must just have full permissions on every object, which isn't quite a superuser.07:27
stubYer. Didn't think of tests issuing DDL.07:27
wallyworld_well, most don't :-)07:28
wallyworld_i'll file a bug and add an XXX to my branch07:28
stubNo need for the XXX really - just a normal comment that os.environ['USER'] is a superuser (or our database setup scripts will completely fail)07:29
wallyworld_stub: i was going to add the XXX so that when the bug i file is fixed, we can replace the os.environ with 'testadmin'07:30
wgrantwallyworld_, stub: Why not use postgres?07:31
wgrantIn test scenarious the current user should be able to auth as postgres, and postgres is both a superuser and the real owner.07:31
stubwgrant: If we know that works for every dev, sure.07:31
wgrantThey have be able to auth as dozens of other users for the test suite to work.07:31
wgrantSo unless they've gone and named them all explicitly...07:32
stubMore that pg_hba.conf often starts with restrictive settings for connecting as postgresql (to ensure autovacuum etc. can work), followed by user settings. But our setup instructions say don't do that, so...07:33
stubwallyworld_: Use 'postgres', no need for the bug or XXXX07:34
wallyworld_ok, thanks07:34
stubwallyworld_: We already switch to that user in other tests07:34
stubwgrant: ta07:35
wallyworld_i tried to find something but there's so many... :-)07:35
StevenKwallyworld_: Can you review https://code.launchpad.net/~stevenk/launchpad/information_type-branch-privacy-trigger/+merge/105291 so I can land it?07:39
StevenKstub: A review of https://code.launchpad.net/~stevenk/launchpad/db-branch-information_type-not-null/+merge/105282 would be lovely.07:39
* stub looks07:40
wallyworld_StevenK: ok, give me a minute07:40
StevenKwallyworld_: It's tiny, only test changes.07:40
stubStevenK: Are you using PG 9.1 yet?07:41
wgrantStevenK: That col is indexed now, right?07:41
StevenKstub: I'm not, but neither was the sampledata in db-devel07:41
stubStevenK: Oh, ok. Thought that the 9.1 version had landed already.07:41
wgrantcjwatson didn't regen sampledata07:42
StevenKIt looks to have in devel, so I will probably have fun with a merge07:42
wgrantI did in devel a few hours back, with 8.4, because I knew there was more coming07:42
stubdiff didn't look that huge - was just checking07:42
stubr=stub anyway07:42
StevenKwgrant: stub did the index the day before the garbo job landed.07:43
wgrantShould be deployable tomorrow.07:43
wgrantYeah, I thought I remembered that, but best to check.07:43
StevenKwgrant: Except that I can't land it yet, since it requires the test fix that I wanted wallyworld_ to review.07:43
* wallyworld_ is looking07:43
wgrantStevenK: That's true. You may have to be lucky.07:44
wallyworld_StevenK: r=me07:45
StevenKYes, rather.07:45
StevenKwallyworld_: I considered changing it to the factory, but decided against it.07:46
StevenKWhy it does INSERT directly is beyond me,07:46
adeuringgood morning07:47
wallyworld_StevenK: i can't recall why. i think it was because it was just testing the triggers and wanted to keep it simple07:49
StevenKwallyworld_: Right, so there is a reason.07:52
lifelesswww.pretotyping.org -08:11
jtvAny reviewers in the house?  I have 2 incremental MPs — https://code.launchpad.net/~jtv/launchpad/bug-994650-scrub-in-batches/+merge/105189 & https://code.launchpad.net/~jtv/launchpad/bug-994650-cache-potmsgsets/+merge/10519308:24
=== almaisan-away is now known as al-maisan
=== al-maisan is now known as almaisan-away
jtvDoes anyone have any tips on how to find, given a job class, what command line we use to run that job?10:20
jtvAhhh, the trail leads to the culprit.  Wow, we can't standardize this stuff soon enough.10:21
wgrantjtv: There's only around 4 ways to run jobs now.10:29
wgrantCelery is a 5th, but will subsume the rest.10:29
jtvlike any One New Standard To Replace All Legacy Standards.10:30
wgrantThis one actually has major benefits over all the existing ones, and is much easier to set up, though.10:43
wgrantAnd is nearly ready.10:43
nigelbwgrant / jtv https://www.xkcd.com/927/12:04
=== matsubara-afk is now known as matsubara
wgrantI don't even need to click the link :)12:10
nigelbI didn't have to actually open the url.12:10
nigelbIt's like 386 is Duty Calls, 705 is Devotion to Duty, etc.12:11
deryckMorning, everyone.13:02
nigelbHey deryck13:04
=== jcsackett changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: jcsackett | Firefighting: - | Critical bugs: 3.47*10^2
deryckadeuring, I'm free again.  want to meet back in the standup hangout?14:14
adeuringderyck: sure14:14
=== almaisan-away is now known as al-maisan
=== salgado is now known as salgado-afk
abentleyadeuring: Could you please review https://code.launchpad.net/~abentley/lazr.jobrunner/rollback-29/+merge/105335 ?14:53
adeuringabentley:  sure14:53
=== al-maisan is now known as almaisan-away
adeuringabentley: r=me14:58
rick_h_jcsackett: if you get a sec pls https://code.launchpad.net/~rharding/launchpad/bugnom_874250/+merge/10531715:02
jcsackettrick_h_: it's in my queue.15:03
rick_h_jcsackett: ty15:03
jcsackettjtv: you around?15:08
cjwatsonwgrant: sampledata> Oops.  Should I have done?15:26
stubcjwatson: Doesn't matter.15:55
stubcjwatson: Just me reconciling what I thought had occurred with reality15:55
jcsackettrick_h_: r=me, with nitpicks.15:57
rick_h_jcsackett: ty, will go check them out.15:58
rick_h_jcsackett: ah, heh I didn't clean that up. Had pdb break points in there so having the middle var allowed stuff15:59
jcsackettrick_h_: dig.16:05
=== salgado-afk is now known as salgado
=== matsubara is now known as matsubara-lunch
=== deryck is now known as deryck[lunch]
=== vednis is now known as mars
=== matsubara-lunch is now known as matsubara
=== deryck[lunch] is now known as deryck
=== salgado is now known as salgado-brb
=== almaisan-away is now known as al-maisan
=== al-maisan is now known as almaisan-away
sinzuijcsackett, ping19:09
jcsackettsinzui: pong.19:12
sinzuijcsackett, have time to hangout>19:12
jcsackettsure, be on g+ in a minute.19:12
=== salgado-brb is now known as salgado
sinzuijcsackett, sorry, lost my phone. I am calling it now19:17
sinzuibugger, g+ changed it's UI again19:20
jcsackettsinzui: i'm still seeing you as offline.19:21
sinzuioh, I think I am in a hangout with you in g messenger19:22
sinzuiNew UI, but same crap19:22
jcsackettyeah, i'm messaging you via g messenger, but still not seeing you online.19:23
lifelessbbiab, shopping run21:07
james_wjcsackett, hi, would you take a look at https://code.launchpad.net/~james-w/launchpad/no-subscription-cancellation-email/+merge/105400 please?21:55
jcsackettjames_w: sure.21:55
=== jcsackett changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: 3.47*10^2
jcsackettjames_w: looks good. if you'll set the commit message i can send it off to ec2 and land for you.21:56
* jcsackett likes short, direct MPs21:56
james_wjcsackett, ace, thanks21:56
james_wjcsackett, done21:57
jcsackettjames_w: may have lied to you, i can't seem to get ec2 to workout properly. sinzui, can you land james_w's branch? i keep getting silent failure on the last step of ec2 land.22:51
sinzuiI can land22:51
=== matsubara is now known as matsubara-afk
rick_h_lifeless: ping22:55
jcsackettsinzui: thanks. MP is https://code.launchpad.net/~james-w/launchpad/no-subscription-cancellation-email/+merge/10540022:55
* jcsackett makes note to poke at ec2 stuff tomorrow.22:55
lifelessrick_h_: ola!22:59
rick_h_lifeless: just commenting on your comment23:00
rick_h_lifeless: bath/bed time for the boy, but will check back in in 30ish. If you want it changed I can, but it was that way with some reason for consistancy. Let me know what you want and I'll update it in the morning23:02
lifelessrick_h_: replies23:04
=== wallyworld changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: wallyworld | Firefighting: - | Critical bugs: 3.47*10^2
=== matsubara-afk is now known as matsubara

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!