[01:24] <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:38] <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:47] <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:48] <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?
[03:05] <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:10] <johntron> jelmer: thanks! i just found reprepo, so i'll probably just use that
[03:10] <jelmer> johntron: ah, rather than a PPA?
[03:13] <johntron> well, i don't want to give the impression that i'll be maintaining this...
[03:14] <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:47] <StevenK> wgrant: No opinions?
[03:51] <StevenK> wgrant: Oh, can't ArchivePurpose.DEBUG die horribly now?
[03:55] <wgrant> StevenK: Back, sorry.
[03:56] <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:58] <StevenK> wgrant: I'm writing my thoughts
[04:01] <StevenK> wgrant: http://pastebin.ubuntu.com/5835072/
[04:02] <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:03] <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:04] <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:05] <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:06] <wgrant> Hm?
[04:06] <wgrant> What do you mean?
[04:08] <StevenK> json_data is not on Job itself, it's on the derived job classes, backing onto their own DB tables
[04:09] <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:10] <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:11] <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:12] <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:13] <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:14] <StevenK> Bleh, derived jobs don't have status directly
[04:14] <wgrant> Create PDJ for what reason?
[04:15] <StevenK> I was thinking to make filtering easy but it still requires two tables
[04:16] <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:18] <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:19] <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:20] <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:21] <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:22] <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:23] <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:24] <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:25] <wgrant> Job.json_data gives us jobs that are almost as lightweight as everyone else who is using celery without the HA concerns.
[04:28] <StevenK> wgrant: I accidently ArchivePurpose.DEBUG, I'm going to self-approve and land.
[04:28] <wgrant> k
[06:02]  * wgrant ginas saucy
[17:02] <cjwatson> Has anyone had a chance to consider https://code.launchpad.net/~cjwatson/launchpad/copy-set-phase/+merge/170775 ?