launchpad-dev team mailing list archive

[Julian Edwards <julian.edwards@xxxxxxxxxxxxx>]

On Monday 22 March 2010 17:28:16 Cody A.W. Somerville wrote:
> The source package build should be associated with the recipe because the
> source package build has nothing to do with the archive except for being
> published there. Off the top of my head, it seems like 'SPRecipeBuild'
> should have a to-many relationship with the 'PackageUploads' it creates as
>  a part of the upload. However, its important that 'PackageUploads' (and
>  the rest of the soyuz classes) continue to know nothing about
>  'SPRecipeBuild'.

That is correct.

However remember that *all* builds are done in the context of an archive as 
this has certain semantics depending on what type of archive it is.  Therefore 
it's possible to associate a set of builds with a particular PPA and that is a 
very useful feature to have.

> The source package upload, and the binary builds, etc. would still be
> associated with the archive like usual.
> 
> >  > This would be a cleaner separation of responsibility
> > >
> > > (enabling further separation of the different apps in the future
> > > etc.).
> >
> > I think that such a separation of responsibility would be artificial.
> > Recipe builds are related to both code and PPAs.
> 
> I think you're mistaken. Soyuz has a discrete set of responsibilities and
> building source packages automatically from branches isn't one of them.

This is correct.

> Although there is a relationship between a recipe build, code, and
>  archives, it should be a loosely coupled one. As I've already mentioned,
>  the archive is just a destination for the output of the recipe build (ie.
>  a source package) to be published.

I've had this conversation with wgrant.  I was also originally saying that we 
should retain the ability to re-upload recipe builds to any archive but he 
pointed out that we can very easily just use the copy feature in the 
publishing model to accomplish this.  We changed the database schema (and 
simplified it) because of this, but I made sure it's easy to add back any time 
we really do need to re-upload.

> > Note: that is not to say that we wouldn't indicate on the PPA page
> >
> > > that there are SPRecipeBuilds currently in progress targeting the PPA
> > > (view/template layer info), just that the SPRBuild isn't traversed via
> > > the PPA and merged with the soyuz binary builds.
> >
> > But where *would* we show all recipe builds affecting the PPA if not
> > there?
> 
> Probably on the recipe build page.

I strongly disagree.  The PPA page is the right place to show builds affecting 
the PPA.

> However... I see the changed-by field being set to the person who requested
> the source package to be published to the particular archive. I also
>  imagine the 'uploader'/'signer' should be the recipe. 

We've modelled a "requester" for this.  For manual builds we'll have the 
person who clicked "do it" and for auto builds it's undecided but most likely 
to be an IPerson who owns the build schedule.

>  I don't think we
>  currently show this distinction in the UI but we should. Once we do that,
>  we could easily look at all the source packages which were uploaded by a
>  particular 'signer' - ie. a particular recipe.

Changed-by is completely separate to the uploader, however in the case of a 
recipe build the lines are blurred a bit.  Perhaps we take the name of the 
last committer on the branch as the changed-by?

> Also, consider this: In the future, maybe archives won't be the only place
> the the output of a recipe build gets published to. Hence, the importance
>  of the loose coupling.

In the future we'll have flying cars^W^W a better separation between an 
"archive" in Launchpad and an "archive" on disk.  The loose coupling here 
applies to the disk-archive.

> <snip>
> 
> >  > Even if it is decided to go ahead with bug 536700, presenting the
> > >
> > > SPRBuilds under the recipe may be worthwhile as a first-cut.
> > >
> > > Thoughts?
> >
> > We will provide a list of recent builds of a recipe, but I think that an
> > overview of all the builds targetting a PPA is also needed.
> 
> Your list could be filterable by the archive it got published to.

Not published to, but uploaded to.  Publishing and uploading are totally 
orthogonal.  So, we upload to a Launchpad Archive, but publish to a disk 
archive.

I welcome nominations for names for these two distinct things!  (I'm tempted 
to split IArchive out into IRepository at some point.)

J