[00:00] wallyworld_: Right, but you need to query the APs to find out the in-use stuff, and the APs include the permitted stuff [00:00] So it can be simplified to just returning the APs [00:01] sure, i was speaking logically as to what is missing [00:42] wallyworld_: Do you think we can Won't Fix bug #1008538 now? [00:42] <_mup_> Bug #1008538: Bug Supervisors are not notified when the project is not shared < https://launchpad.net/bugs/1008538 > [00:43] perhaps. we were waiting for everything to be migrated across i think [00:44] so can't we just leave it in open till then? [00:44] I guess [00:44] I just don't really think there's much we need to do in terms of it now [00:44] Or in the future [00:46] i think we were going to create structural subscriptions [00:48] Mmmm, possibly. [01:20] when using launchpadlib, how can a bug_task.status == u'Triaged' and bug_task.date_triaged == None :( [01:23] cr3: Possibly if it was created Triaged [01:24] wgrant: interesting, so I'll fallback to date_created when any of the status related dates is None. thanks! === bigjools-afk is now known as bigjools [01:56] wgrant: https://oops.canonical.com/?oopsid=8dffb8ed96a390893ecaef560b7af41a [01:58] StevenK: wallyworld's thing will fix that [01:58] Though there is an underlying bug that should also ideally be fixed [01:59] if the branch scanner ever completes :-( [01:59] wallyworld_: You linked the bugs before the scan completed [01:59] It's cursed [01:59] wgrant: What's the underlying bug? [01:59] linking bugs is ok [01:59] creating mp is not [01:59] wallyworld_: Evidently not :/ [01:59] i've linked bugs without problems for ever [01:59] but creating mp is problematic [02:00] Doing *anything* with a LP branch before its scanned leads to cursing. [02:00] Even looking at it. [02:00] hmmm. not for me till now [02:00] i've tried the push -r-2 trick. what else can i try? [02:00] Renaming the branch on LP and re-pushing [02:00] besides that :-( [02:01] Nothing [02:01] balls [02:01] Besides SQLing the BRs away without a timeoput [02:01] Haha [02:01] In general, don't touch a large branch before the initial scan completes [02:02] Can we delete BranchRevision for being complete crap? [02:05] [2012-09-03 02:01:54,379: INFO/PoolWorker-2] Job resulted in OOPS: OOPS-5de0a53e4be5589c2a0309cbe7f925b9 [02:05] anyway [02:06] PoolWorker-2 really is cursed [02:06] Bleh [02:06] Can't add a team to +sharing, so can't change the owner of the branch [02:07] Or maybe this thing has a BVP, which would be quite sad [02:08] StevenK: Oh, sorry, meant to say: you can work around that one by just setting Private and Private Security to All. [02:08] As well as Proprietary [02:08] the first two will do nothing [02:08] But it should prevent the crash [02:08] * wgrant tries [02:08] Yeah, that worked out it [02:08] around it, that is [02:09] Hah [02:09] +sharing for me states the branch is Private, when the branch itself states it is Proprietary. [02:10] Have you refreshed? [02:10] Where does +sharing state that it's private? [02:10] I don't see that [02:10] Oh [02:10] +sharing/stevenk [02:10] That is interesting [02:10] Quite [02:11] 'cause the APA is correct [02:11] Maybe we have a bug in PersonPillarSharingView? [02:11] However it's named. [02:12] I assume so [02:12] Or possibly in the sharing service, probably [02:13] # At the moment, all branches displayed on the sharing details [02:13] # page are private. [02:13] information_type = InformationType.USERDATA.title [02:13] Face. Palm. [02:13] heh [02:14] Sounds like an easy fix [02:14] Yeah, I'll look at it [02:14] i think that stuff was written for the sharing details page way before information types [02:16] Before they were implemented properly for branches, yes [02:21] * StevenK tries to work out where the tests for PillarPersonSharingView are hiding. [02:40] wallyworld_: I don't think PillarPersonSharingView is tested. :-( [02:41] StevenK: not sure, i didn't write it. i can look [02:41] wallyworld_: Second set of eyes would be excellent [02:42] StevenK: PillarSharingDetailsMixin [02:42] test_pillar_sharing [02:43] so TestProductSharingDetailsView etc extend the mixin [02:45] wallyworld_: Ah ha! Thanks [02:45] np [02:45] the tests look like they could have some added [03:00] Bah. [03:01] I have it create a proprietary branch, and it dies creating an APA saying it already exists [03:01] You shouldn't need to manually create APAs any more [03:04] Heh, nice. Dropping the APA lines gives me +22, -23 [03:05] * StevenK will push the branch up and propose after lunch [03:06] Actually, no. Since my lunch has to cook, I'll put it on and then push the branch [03:20] wallyworld_, wgrant: https://code.launchpad.net/~stevenk/launchpad/branches-are-more-than-private/+merge/122436 [03:22] StevenK: i'd add the test to the subclass [03:22] if it's only applicable for products [03:23] i'd also just call the test view_data_model_branch , remove the word proprietary [03:24] wallyworld_: branches are already tested by test_view_data_model, I was trying to be clear. [03:25] hmm. i'm not sure we need a separate test then. we dont' have a separate test for proprietary bugs [03:26] wallyworld_: So, I can rename it to proprietary, create a bug as well and check that both of their information_types are golden? [03:27] do we need to? so long as the data model tests check that the json info type matches that of the artifact, aren't we ok? [03:27] ie is the existing test sufficient? [03:27] wallyworld_: So the [03:27] Sigh [03:28] i guess i'm asking, why doa special test for one specific info type [03:28] wallyworld_: So the problem was that the existing tests create a bug and branch as USERDATA and then assert that is what is in the JSON. [03:28] maube should need to loop across all info types then [03:28] wallyworld_: The UI was overriding all branches information_type to USERDATA -- so I'm creating a branch that is a type that isn't USERDATA and checking what's in the JSON. [03:29] I could use PRIVATESECURITY just as well [03:30] yeah, understood [03:30] i guess i have a small issue with adding a new test just for one specific info type. we should have a general test that lops over all info types if we don't trust the test that's there [03:31] or change the info type to != USERDATA [03:31] as you suggest [03:31] that may be easiest [03:32] since it gives us a failing test before the code change, and a working test after the fix [03:59] wallyworld_: Sorry, was noming. http://pastebin.ubuntu.com/1182844/ [04:00] np, let me look [04:01] StevenK: sure, but i think we don't even need a whole new test. just make the current data model test fail by changing the info type of the branch to PS or something other than UD, and the code fix makes everything ok again [04:13] wallyworld_: Oh, HAH [04:14] wallyworld_: I can't do it that way -- the branch is created as USERDATA and the JSON is populated on view creation so I can't transition it away, which would have been why I created a new test in the first place. [04:15] * StevenK sees if he can grab the branch before the view and transition there. [04:16] can can change the makeArtifactGrantee method [04:17] I can change it to create a PRIVATESECURITY branch, sure [04:18] and that will make the test fail without the code fix [04:18] so i think that's all you need === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [04:23] wallyworld_: http://pastebin.ubuntu.com/1182879/ [04:25] StevenK: i think that's ok. minimal changes, but the tests still fail without the code fix being applied [04:25] And they do, yes. [04:25] cool. adding a new test in this case just didn't sit right weith me [04:29] StevenK: see, i even got you some LOC credit [04:30] wallyworld_: Mercy buckets [04:31] wallyworld_: It's not like I needed more. [04:31] % loc-contributions 'Steve Kowalik' [04:31] -3236 [04:31] well give some of yours to me then [04:31] :-P [04:31] wallyworld_: I would if I could === StevenK changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: 4.0*10^2 === StevenK changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: ∞ [04:37] That's better. [04:42] lol [04:47] i'd love to revisit out bug triage policy based on these numbers [04:49] http://webnumbr.com/launchpad-critical-bugs :) [04:50] no, i meant i disagree with the triage policy [04:51] I know, I was just showing you some even prettier numbers [04:51] * micahg stopped filing timeout bugs [04:53] wgrant: That user destroyed thier MP [04:53] Which is unfortunate, I wanted to grab sinzui's testcase off it [04:54] StevenK: I can forward the email if you wish [04:54] wgrant: From Curtis? Please do [04:56] This is why we shouldn't allow anybody to ever delete anything :) [04:56] No, we need to congratulate him -- he managed to delete a Launchpad branch [04:57] You have a good point... [05:10] He is nothing but persistant [05:10] He's put another branch up which actually fixes the issue, but doesn't include a test. [05:19] wallyworld_: Is PopulateProjectSharingPolicies done? [05:20] Yes, it can die [05:20] stub: O hai, https://code.launchpad.net/~stevenk/launchpad/drop-unused-branch-function/+merge/122431 would love a review [05:20] As of Friday all projects are created with either Public or Proprietary [05:20] I'll kill it [05:20] There's even a card for it [05:39] StevenK: Applied happily to qastaging. Guess I should run it on production. [05:39] staging is rather borked - empty db [05:40] Haha, ouch [05:40] stub: Let me lp-land it [05:42] stub: Aren't we in the middle of backups? [05:42] probably, but that doesn't matter for this [05:42] That is only a problem for live index builds [05:43] Right, okay. [05:47] wallyworld_, wgrant: https://code.launchpad.net/~stevenk/launchpad/destroy-populate-project-sharing-policies/+merge/122442 [05:53] StevenK: +3? :( [05:55] wgrant: Oh, bleh. [05:55] And all of those 3 are imports that went from multi-line to single, so shush [05:55] It was worth a try. === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [06:44] wgrant: i just had a look at the accesspolicy code - are you stre the other delete methods just pass in ids? see for example def delete(cls, concrete_artifacts): [06:46] wallyworld_: Natural keys, not necessarily primary keys [06:47] hmm. ok. seems a bit superfulous if i have the objects [06:47] Yeah, but the inconsistency is a bit bad [06:47] i'll now have to unpack them just to apss them in [06:47] Note that it's delete(concrete_artifacts), not delete(abstract_artifacts) [06:52] One could argue that these shouldn't really be objects at all :) [06:52] But mumble mumble [07:18] i agree. i prefer to delete using just ids [07:20] Right, but it's a toss-up between the performance-based surrogate key and the natural key. [07:45] good morning === Peng_ is now known as Peng === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === Ursinha_ is now known as Guest32164 === al-maisan is now known as almaisan-away [16:26] ah, staging is dead. That would explain my inability to do much of anything with the API. [16:28] hmm [16:28] getting it kicked [16:29] ev: people are on it and it's being restored [16:29] yay === salgado is now known as salgado-afk === Ursinha is now known as Guest39611 [18:07] o/ === dpm is now known as dpm-afk [18:15] hi [18:17] jml: oh hi [18:33] jml: did you review my fixtures branch ? [18:33] lifeless: maybe? [18:33] * jml looks [18:34] jml: there is a class in there that wants to be free, pondering a new pypi project for it [18:34] lifeless: yes, I reviewed. [18:35] ahha so you did. Thanks [18:35] lifeless: I'd wait until there was a project that wanted CallMany & didn't want anything else of fixtures [18:35] jml: like testtools :P [18:46] lifeless: huh, I guess so. [18:46] lifeless: "Hard Facts" is a great read, btw. [19:01] jml: it is, isn't it! === cjohnston_ is now known as cjohnston === salgado-afk is now known as salgado [21:21] any reviewers around ? https://code.launchpad.net/~lifeless/python-oops-datedir-repo/bug-960775/+merge/122580 [21:27] ev: o/ [21:27] ev: will reply to your mail today [21:38] lifeless: we're down some due to USA being off today [21:40] yeah [21:40] I can still hope :) [21:44] true :) [21:44] lifeless: hows the little one? [21:47] just had a growth spurt [21:47] was eating massive amounts every couple of hours for 3 days [21:50] heh keeping ye busy I'm sure [21:51] yah [21:51] I was at kiwipycon in the weekend [21:51] we could have done with more sleep :P [21:52] I was at a 2 day Irish wedding , my liver isn't speaking to me [21:55] LOL [22:36] any reviewers around ? https://code.launchpad.net/~lifeless/python-oops-datedir-repo/bug-960775/+merge/122580 <- StevenK [22:37] wgrant is OCR today. :-) [22:38] StevenK: its small and you're doing work already :P [22:38] lifeless: I'm in the middle of a few things, I'll look at it after if someone else hasn't already grabbed it. [22:38] OTOH so is wgrant I see [22:39] StevenK: thanks!; I'll whinge at wgrant right now. [22:39] * lifeless whinges [22:39] Default state, isn't it? [22:41] por moi? [22:43] lifeless: 44 + except IOError, e: [22:43] 45 + if e.args[0] == 'Empty OOPS Report': [22:43] Really? [22:47] * cjwatson bangs the Python 3 compatibility drum a little [22:49] (s/,/ as/) [22:50] cjwatson: I might care if we deployed on !lucid [22:51] neem is precise [22:52] We don't deploy on so as is fine [22:52] lucid is python 2.6 isn't it ? [22:52] I thought as was 2.7 [22:52] wgrant: this gets deployed on the various servers - e.g. everywhere. [22:52] 2.6 has as [22:53] LP uses 'except ... as' [22:53] Right, we use it in lots of places in LP [22:53] It's not new in 2.7 [22:53] Everywhere - I went through and fixed everything using the old style [22:53] Ah, indeed [22:55] https://code.launchpad.net/~cjwatson/launchpad/new-style-except/+merge/112727 [22:56] so sure, will change. [22:56] cjwatson: everywhere in the main code tree; I guarantee lots of untouched places :) [22:56] wgrant: as for the inspection, yes, really. [22:56] Well, yes, but enough that I also guarantee it will work for you [22:56] lifeless: :( [22:56] Life's too short to figure out how to submit patches to everything else [22:56] wgrant: lower layer signals that way [22:57] cjwatson: sure, theres about 20 projects that have the same submission process as lp:launchpad :> [22:57] lifeless: :( [22:57] cjwatson: but I understand the overhead [22:57] And a bunch that don't [22:58] Also about 50% of the time reviewers seem faintly confused when I submit a patch to one of the other projects [22:58] cjwatson: :( - thats sad, a little understandable, but sad. [22:59] I probably need to beat that drum some more [22:59] Mostly about how to deal with landing [23:00] cjwatson: ah, so thats more tractable [23:01] wgrant: I can change the signalling, but honestly it doesn't seem worth a specific class [23:08] lifeless: OK === Ursinha` is now known as Ursinha === Ursinha is now known as Guest21289 === Guest21289 is now known as Ursinha