launchpad-dev team mailing list archive

[Julian Edwards <julian.edwards@xxxxxxxxxxxxx>]

Right, I just had a good call with Jono and we've cleared a bunch of stuff up 
between us.

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.
 2. SourcePackageRecipeDataBranch needs a revision number.  This is more 
pertinent to manifests but Jono tells me it should be used for recipes too.
 3. SourcePackageBuildUpload should have a requester column

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!

> > 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.  
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.

In other words, your schema patch is fine :)

> 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.

> >> 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.

> 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.

Cheers
J