Julian Edwards wrote: > Right, I just had a good call with Jono and we've cleared a bunch of stuff up > between us.
Excellent. > The upshot is that you need a few more changes to the schema: > > 1. SourcePackageRecipeData needs a "type" column so we know if it's a > manifest or a recipe. This will help with indexing, especially since we'll > have loads more manifests than recipes. I'm not sure I see why, but OK. > 2. SourcePackageRecipeDataBranch needs a revision number. This is more > pertinent to manifests but Jono tells me it should be used for recipes too. Um, revision *number*? I would have thought a text revspec or revision id field would make more sense. I'd like to talk about this bit some more I guess. > 3. SourcePackageBuildUpload should have a requester column Cool, I'd already come around to this point of view. > More below: > > On Thursday 03 December 2009 02:19:54 Michael Hudson wrote: >> I hope this makes sense now, and I apologize for not being clear on this >> before. > > Much better, thank you! Hooray. >>> Yes, we do. Right now we track this via Build.buildstate. Each >>> "xxxBuild" should have similar thing. It would be nice to part-refactor >>> this into some other table but I think it's too much hassle to change the >>> Soyuz code for this versus the benefit. >> I guess for SPBuild we won't use that buildstate value then. > > Quite the opposite, you'll need it to track what's going on with the SPBuild. I meant 'SPBuild will never have this particular value from BuildState that indicates an upload has happened in its buildstate column', it's clear that SPBuild needs a buildstate column. Though now I look at the code, I don't really understand how the uploaded-ness is tracked through buildstate. > In fact the existing lp.soyuz.interfaces.build.BuildStatus will continue to > apply for all build job types. We need to move that enum somewhere else now > though. lp.soyuz.enums! Worked well for code, that idea. > In other words, your schema patch is fine :) Yay. >> Currently in my patch, SourcePackageBuildUpload doesn't have a >> requester, should it? I guess maybe it should, 'id, date_created, >> registrant' are the standard fields after all... > > Yes, I think it should. Soyuz separately tracks who requested an upload. > This can be different from who built a package (consider a MOTU sponsoring a > package for example). > >> But I think I'd like to keep the Job row separate from the Build row. > > Separate as in separately deleteable? That should be ok. Yes. Cool. >>>> Would it be accurate to say that in a world where all builds are done >>>> through branches and not dput that we would still have >>>> SourcePackageReleases but not PackageUploads? >>> Not really, we still need to model uploads. >> But all the uploads would be from "inside" the system, all source >> packages would be built by Soyuz as well. > > That doesn't matter. Right now, "inside" uploads from the build system go > through the exact same process as source uploads from outside the system. > That is, the buildd-manager puts .deb packages coming from the builders into > the same incoming queue as the ftp uploads from outside, and calls the same > script to process the upload. Right. >> Hopefully tomorrow I can spend longer writing code than emails! > > Yes, that'd be great :) :) > We might catch jml in the airport before his flight leaves for Sydney at > 22:00 > today and get this puppy reviewed and done. Otherwise, he'll look on Monday. > > In eitther case, I think you might as well start coding on the assumption > it's > not going to change much. Either way is OK, sounds like major changes are not going to be required. Cheers, mwh _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
