On Monday 22 March 2010 16:02:16 Michael Nelson wrote: > On Mon, Mar 22, 2010 at 3:35 PM, 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? > > Cody might reply himself, but I think his point was that soyuz is (or > should be) all about managing archives - publishing both source and > binary packages and their indexes etc.
A PPA is a special case of an archive, therefore I think it should have the recipe builds listed there. The archive management aspect is orthogonal[1] and at some point there will be a split where we move IArchive into a separate module. > Since SourcePackageRecipe isn't something that gets published in an > archive, it seems a bit strange to centre its associated build in the > archive context. Not an archive context per se, but a *PPA* context. i.e. the specialisation of an archive. It might help to think of the area on disk as an "archive" and the Launchpad objects as a PPA, a Rebuild etc. > But that's not to say (IMO) that the PPA UI shouldn't allow users to > view all the SPRBuilds targeting that archive, my main concern is the > context of the actual SPRBuild traversal itself (ie. do we traverse > through the recipe or the target PPA), and from what you've said > below, it'll be the recipe so I'm happy :) Yes, I think it should be the recipe. > > 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. > > I agree that we need to have a page that lists all the SPRBuilds for > an archive, and trying to imagine other places within a PPA where that > could/would be leaves me thinking that you're right - as a user the > most logical place I'd look is the ppa/+builds. Cody? We absolutely need a single place to go to see all PPA-related stuff. There's already a +builds page so what I'd like to see are the recipe builds in that list, with another filtering option in the drop-down. > Sorry, I didn't mean that the user should get to them via the recipe > only, but that the URL itself for a recipe build should be something > like recipe_url/+builds/build_id. This is how I read it too. > >> I just checked the code teams initial cut document at: > >> https://dev.launchpad.net/BuildBranchToArchiveUI/InitialCut > >> > >> and saw there that a recipe will already have it's build history (ie. > >> recipe_url/+builds), so it would seem to make sense to present the > >> builds themselves under this traversal and only be a small step. > > > > I don't understand. That is already the plan. What is the small step > > you are proposing? > > So I clarified on IRC with you that you are planning to have: > > recipe_url/+builds > > but that you have no opinion whether the individual SPRecipeBuild url > should be off the recipe or the PPA. [snip] > Agreed. So my question should have been be narrowed down to, "Should > the url for a source package recipe build sit off the recipe: > > recipe_url/+builds/unique_build_identifier > > or off the PPA: > > ppa_url/+builds/unique_build_identifier" It should definitely be recipe_url/+builds/build_id so that it's consistent with source package build URLs. J _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
