launchpad-dev team mailing list archive

[Aaron Bentley <aaron@xxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cody A.W. Somerville wrote:
> On Mon, Mar 22, 2010 at 10:35 AM, Aaron Bentley <aaron@xxxxxxxxxxxxx
> <mailto:aaron@xxxxxxxxxxxxx>> wrote:
>     How is that different from a binary package?  Is it because the source
>     package that the binary is built from is also in the PPA?
> 
> 
> I hope you're not suggesting that SPRecipeBuilds won't have the
> resulting source package from the recipe build published to the archive.

I'm not.  I was trying to understand the distinction being drawn between
binary builds and source-package-recipe builds.  AIUI, both can have a
PPA as their target, but only binary builds can have a PPA as their source.

>     This seems to be a distinction based on our organizational structure,
>     rather than on user needs.  Responsibility for recipes could plausibly
>     have been given to Soyuz, and if it had, this argument would evaporate,
>     right?
> 
> 
> It could have plausibly have been give to the Soyuz team but that would
> have been a mistake IMHO. I feel its helpful to think of Soyuz as a
> discrete service and Code hosting as a discrete service. BuildFromBranch
> is also a service but one built by consuming the services provided by
> Soyuz and Code hosting. BuildFranchBranch would fetch the branch from
> Code hosting, build a source package, and then upload the resulting
> source package to a target archive. Soyuz its self should not care that
> the source package came from BuildFromBranch service - it should see it
> as just another source package it needs to build.

I agree that this is a distinction that could be made, but I'm not sure
it should be.  The way I see it, build from branch is a service provided
by the Soyuz build farm that uses Code branches and outputs to Soyuz PPAs.

> This, to be clear, is
> not to say that additional meta data should not be presented in the UI
> to make it easier for users to understand where the source package came
> from. However, the 'SPRecipeBuild' should be associated with the branch

Definitely not with the branch

> (or probably more appropriately the recipe if a branch can have more
> than one recipe)

They can

> it was built from and not directly with the archive the
> source package was published to. Besides architecturally being sound,
> also consider that it seems that it should be entirely plausible to
> publish the same 'SPRecipeBuild' to multiple archives.

We don't do that.

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

What else can a build do with an archive?  Use it as a source?  See "I
was trying to understand the distinction..." above.

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

Why is that?

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

Yes it is.  It's the Soyuz build farm, it's the Soyuz build system.  We
wouldn't have needed a shared sprint if SPR builds were just a Code thing.

>     But where *would* we show all recipe builds affecting the PPA if not
>     there?
> 
> 
> Probably on the recipe build page.

The recipe build page will only include builds of that recipe targeting
that PPA.  It won't include builds of other recipes or binary builds.

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

That wouldn't include all the builds targetting a PPA.

> Its
> important to have clear division of responsibility, loose coupling, and
> high functional cohesiveness.

Loose coupling has advantages and disadvantages, and I think if we try
to apply it to this service, the disadvantages will outweigh the advantages.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkunt0EACgkQ0F+nu1YWqI0CBwCggjNYFZ4+Ht9A+OO4EYKutqzM
5RcAnipXuKBEDBJoA+5q0lxrgIJTm3Df
=EiIH
-----END PGP SIGNATURE-----