launchpad-dev team mailing list archive

[Michael Nelson <michael.nelson@xxxxxxxxxxxxx>]

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.

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.

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 :)

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

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

See above about what gets published in an archive etc. I don't think
his point was about organisational responsibility, but rather the
responsibility of an archive publishing system.

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

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.


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

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

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"

Cheers,
Michael