[01:24] wgrant: So I hang myself with dispair over Django and its ORM, I've been poking at PackageDiff. I'm still tossing up if we write a PDJ and hook everything that way, or if I keep PackageDiff as it is and write a new class that pretends to be an IJobSource [01:24] Er, so I don't hang myself, even [01:38] how do i import a github repo? i see the page that says it's possible, but it doesn't actually say how: https://help.launchpad.net/Code/Imports [01:38] nvm [01:38] * johntron is an idiot [01:47] i dunno if i'm just dense or not, but i can't figure this out. i want to create a source package recipe using this as a starting point: https://launchpad.net/~chris-lea/+archive/nginx-devel [01:48] i see that i can copy it, but don't know how to get the bzr repo checked out [01:48] maybe i need to just download the .deb and create my own repo from that? [03:05] johntron: you'll need to download the source pakcage and create a branch from that [03:05] from the debian/ directory there specficially [03:10] jelmer: thanks! i just found reprepo, so i'll probably just use that [03:10] johntron: ah, rather than a PPA? [03:13] well, i don't want to give the impression that i'll be maintaining this... [03:14] i was just wanting to use PPA to build and distribute for me [03:14] so i can use puppet/chef/salt to provision easily [03:47] wgrant: No opinions? [03:51] wgrant: Oh, can't ArchivePurpose.DEBUG die horribly now? [03:55] StevenK: Back, sorry. [03:56] Ah yes, I forgot to follow up to kill the enum value [03:56] StevenK: I'd write a PDJ [03:56] You can possibly get away with just using the job table. [03:58] wgrant: I'm writing my thoughts [04:01] wgrant: http://pastebin.ubuntu.com/5835072/ [04:02] 1) is right out, because you used the word "leverage" [04:02] Haha [04:02] PackageDiff.job to replace PackageDiff.status is an antipattern [04:02] It could supplement it, but it cannot replace it. [04:02] wgrant: Currently, ISourcePackageRelease.package_diffs will show PENDING diffs, too [04:03] That's correct. [04:03] I'm not sure if we care enough to preserve that behaviour. [04:03] We do [04:03] We don't particularly want duplicate diffs requested [04:04] And it will confuse eg. +localpackagediffs [04:04] So we want PackageDiffJob.package_diff and PackageDiffJob.job, and we create a PackageDiff when the job is created [04:05] And PackageDiff.status and its enum friend can die. [04:05] I think you can probably get away with using Job.json_data [04:05] Or whatever it is called [04:05] Referential integrity is not an issue here [04:05] The job should just not do anything if the PackageDiff doesn't exist. [04:05] So no DB changes [04:05] Until status dies? [04:06] Hm? [04:06] What do you mean? [04:08] json_data is not on Job itself, it's on the derived job classes, backing onto their own DB tables [04:09] wgrant: If we're linking to Job to make use of Job.status, why does PackageDiff.status need to exist? [04:09] StevenK: We're not linking to Job [04:09] The Job will be linked only be a reference in a JSON dict. [04:10] And even if we were linking them formally, PackageDiff.status still needs to exist unless we want to break Launchpad [04:10] If we create PDJs (say), we can automatically fail the job if the SPR is udev [04:10] No [04:11] Because that bug will be fixed by the time this happens. [04:11] I'm also not sure how that's relevant to this [04:11] wgrant: We can't use Job itself [04:12] wgrant: How does the death of PD.status break LP? [04:12] Why can't we use Job itself? [04:12] We may need to add a new JSON column to it [04:12] But I don't see why we can't use it [04:13] StevenK: Because filtering by (SPR, status) across two tables is going to be very slow [04:13] Think BPB, except not from 2005. [04:13] Then we create PDJ? [04:14] Bleh, derived jobs don't have status directly [04:14] Create PDJ for what reason? [04:15] I was thinking to make filtering easy but it still requires two tables [04:16] Even if PDJ.status existed, it still provides no benefit [04:16] Why do that when you can just use PD.status? [04:18] wgrant: So, we create Job.json_data, when a PD is requested we make a bare job that contains the PD id in json_data, and then we have a interface/model that grab the job, lookup the PD, perform the diff and set PD.status appropiately? [04:18] Unless you can think of a benefit to having PDJ [04:19] Not having PDJ means it's different to any other job via process-job-source ? [04:19] I mean in the database [04:19] process-job-source has no idea about the database layout [04:19] Code changes within Launchpad are cheap [04:20] They can easily be changed with an hour's notice [04:20] A PDJ table provides no benefit, apart from a foreign key reference, and I would argue that that is not a benefit. [04:20] And it pushes us ever closer to 300 tables [04:21] If you follow the "everything needs a foreign key" approach then you end up needing a separate table for every distinct set of classes that participate in a job [04:22] We can't destroy hwdb and kill 16 tables? [04:22] I haven't spoken to HWE/cert [04:22] lately [04:23] Even so [04:23] a PDJ table provides no benefit other than an FK [04:23] FK is not a notable benefit [04:23] => PDJ is a net negative [04:23] => no PDJ table [04:23] You still need a DB change this time. [04:23] But only this time. [04:23] So, the plan I outlined is fine? [04:23] Yes [04:24] It's effectively a schemaless rabbitmq job that happens to also be persisted in the database, because we don't have a rabbitmq HA story today. [04:25] Job.json_data gives us jobs that are almost as lightweight as everyone else who is using celery without the HA concerns. [04:28] wgrant: I accidently ArchivePurpose.DEBUG, I'm going to self-approve and land. [04:28] k [06:02] * wgrant ginas saucy === tasdomas_afk is now known as tasdomas === wedgwood_away is now known as wedgwood [17:02] Has anyone had a chance to consider https://code.launchpad.net/~cjwatson/launchpad/copy-set-phase/+merge/170775 ? === tasdomas is now known as tasdomas_afk === wedgwood is now known as wedgwood_away