launchpad-dev team mailing list archive

["Cody A.W. Somerville" <cody.somerville@xxxxxxxxxxxxx>]

Hello,

Disclaimer: I've only given passing thought to this in a discussion with
Michael. Furthermore, the discussion was of a much broader subject then just
this topic so some of the points I bring up will have more to do with that
discussion then this particular problem. Lastly, I don't think this e-mail
will cover all the points I brought up with Michael so please feel free to
ask further questions if something I say doesn't seem to compute.

On Mon, Mar 22, 2010 at 10:35 AM, Aaron Bentley <aaron@xxxxxxxxxxxxx> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Michael Nelson wrote:
> > I was recently convinced by Cody (who has other motives ;)) at our
> > soyuz sprint that it could be a Bad Idea. His point was (correct me
> > where necessary Cody) that a SPRecipeBuild is only related to a PPA
> > because the resulting source package will be uploaded to the PPA.
>
> 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 think that it would be useful to have a page that lists all the builds
> that will affect the PPA, and +builds is the obvious place for it.  We
> can, of course, provide filters to only show binary builds, if users
> want that.
>

> > That
> > is, the resulting source package belongs in soyuz in the PPA context
>
> 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. 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 (or probably more appropriately the recipe if a
branch can have more than one recipe) 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.


>
> > but the recipe builds associated with a recipe should be traversed via
> > the recipe.
>
> Why?
>

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

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

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

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

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.

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


> Aaron
>

This all being said.... ultimately, my concern had more to with the
architectural implementation and less to do with how the information is
actually presented in the UI (although please don't interpret this to mean
that I feel you should disregard my opinion on the matter). Its important to
have clear division of responsibility, loose coupling, and high functional
cohesiveness. Less interdependency means less need for co-ordination and
less need for information flow (both in our code and our teams) which is
highly beneficial for a distributed group like ours.

Cheers,

-- 
Cody A.W. Somerville
Release Engineer
Foundations Team
Custom Engineering Solutions Group
Canonical OEM Services
Phone: +1 781 850 2087
Cell: +1 613 401 5141
Fax: +1 613 687 7368
Email: cody.somerville@xxxxxxxxxxxxx