launchpad-dev team mailing list archive

[Julian Edwards <julian.edwards@xxxxxxxxxxxxx>]

On Monday 22 March 2010 16:02:16 Michael Nelson wrote:
> On Mon, Mar 22, 2010 at 3:35 PM, 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?
> 
> 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