launchpad-dev team mailing list archive

[Michael Hudson <michael.hudson@xxxxxxxxxxxxx>]

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