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 <[email protected]> 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: [email protected]
_______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
