-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cody A.W. Somerville wrote: > On Mon, Mar 22, 2010 at 10:35 AM, Aaron Bentley <[email protected] > <mailto:[email protected]>> 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----- _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
