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