launchpad-dev team mailing list archive

[Michael Nelson <michael.nelson@xxxxxxxxxxxxx>]

On Fri, Feb 5, 2010 at 3:58 PM, Aaron Bentley <aaron@xxxxxxxxxxxxx> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Michael Nelson wrote:
>>
>> I don't think I understand. As far as I can see, everything (except
>> the recipe name) that we're asking for on these mockups:
>>
>> http://people.canonical.com/~michaeln/bfb/build_now_overlay_without_recipe_structure.png
>>
>> is required to create a build (whether you mention recipes or not)
>> (See below about the package name). That is, distroseries selection,
>> deb version and the packaging branch.
>
> Right, and we may be in furious agreement.  Bear in mind that I was
> looking at these mockups:
> http://people.canonical.com/~michaeln/bfb/build_now_overlay.png
>
> I haven't seen your new mockups 'till now.  Your new mockups hide the
> recipe, showing only domain-specific fields.  Your old ones showed a
> generic interface where a packaging branch was only implied, not specified.

They're just a few alternatives to discuss atm.,, I added that one
after Martin's email earlier (you can see them all on the wiki page).

> I remain uncertain that recipes are as flexible as we would want for
> this.  Your bug https://bugs.launchpad.net/bugs/516496 suggests that as
> currently formulated, they specify too much by having revision specs.

Yes, I'm guessing we'll be tweaking the backend implementation as we
start trying to use these. MichaelH did a great job getting all the
model code into trunk, but it'll take time to settle (IMO).

>> Aside from that, it would mean that other people couldn't benefit from
>> being able to see what recipes are available for a branch and re-use
>> them (especially if we flooded the recipe table with new recipes for
>> each build).
>
> I was proposing storing the domain-specific values, rather than the
> recipes, and that would be something others could reuse.

I see, like *storing* a 'packaging_branch' attribute, rather than the
parsed SPRDataInstruction that contains the merge instruction. That
might be worthwhile bringing up in your team.

>
>> Now I'm guessing your point would be, if we instead got rid of the
>> recipe interface and just allowed the user to specify a build, we
>> don't need to support re-usable deb versions strings and that's true
>> as long as we don't want the same interface to support daily builds.
>
> No, I definitely want our solution to work for daily builds.  I actually
> think specifying a template deb version is fine.


>>> I thought the debian control directory specified the package name.
>>
>> Yes they do, hence the bug "Recipe requires sourcepackagename before upload"
>> https://bugs.edge.launchpad.net/launchpad-code/+bug/515581
>
> Okay, but doesn't that still contradict your statement that we can't
> always know the package name from the branch?

Not that I'm aware of... when we create the SPRecipe, we need to
supply a sourcepackagename, and at that point-in-time, the only
guaranteed place where I can get that information is the changes file,
which I *thought* I didn't have access to from LP (until it's uploaded
after the recipe build succeeds). But let me know if I've
mis-understood something.

>
>> It would be nice if the sourcepackage name wasn't required when a
>> recipe is created, but as I understand it, the URL traversal that was
>> previously decided on requires it:
>>
>> (code?) ~owner/distro/distroseries/sourcepackagename/recipename TheSo
>> canonical traversal for displaying/editing a recipe.
>
> There are probably ways we could get around it, e.g. by looking at the
> contents of the package branch while creating the recipe.  Not sure
> there's value in that.

Oh, I was under the impression that wasn't possible/allowed from an LP
app server.

>
>>> If we're not exposing recipes, why should the user care about
>>> duplication?  Yes, it would be nice to remember past settings, but
>>> again, that doesn't require recipes per se.
>>
>> As above, I'm not sure how it wouldn't require saving the "set of
>> build inputs" with a user-specified name so they can re-use it (which
>> is what we've got with a recipe).
>
> It would require that, but instead of a recipe, it would be entirely
> domain specific, and would fit our needs exactly.

OK, I guess that's a great point to pick up on a phone conversation on
Monday (so I can understand exactly what would be different from what
we're currently displaying).

Thanks Aaron!