launchpad-dev team mailing list archive

[Aaron Bentley <aaron@xxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Nelson wrote:
> On Thu, Feb 4, 2010 at 7:06 PM, Aaron Bentley <aaron@xxxxxxxxxxxxx> wrote:

>> Doesn't a user actually want to specify a list of distroseries you want
>> to build for?  And don't you need a recipe per distroseries as currently
>> formulated?
> 
> Yes, that would be great, and given that we've got a distroseries
> field on the SPRBuild as well, we *could* actually create separate
> SPRBuilds from the one SPRecipe (bug 513201). As James noted, it's not
> the most efficient way - it would be better if soyuz could do some
> magic and build the source once and tweak it for multiple
> distroseries.

I guess I fear that source packages built from the same recipe on
multiple distroseries can legitimately have other differences, and that
this could be lost.  But this is not my domain.

>> I don't think that follows.  Recipes are only somewhat specific to
>> packaging.  Providing a UI that was less generic and more
>> domain-specific could be quite helpful.
> 
> 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.

In the new interface, the user doesn't see any recipe commands, and the
packaging branch is referred to as a packaging branch, not as an
arbitrary branch to be merged.  That's very much the sort of thing I was
proposing.

So the difference remaining is that you still have users editing
recipes, though usually indirectly, while I would generate the recipes
dynamically from settings like the ones you show.

> And I would have thought it would be useful to be able to re-use that
> information next time I want to do a build

Sure, and I was already saying that would be a good idea.

> and the most obvious way
> to do that is to save it as a recipe with a name that makes sense to
> me (foo_branch_with_my_packaging).

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.

If we were to look at your "build this revision" scenario with a UI that
didn't directly edit recipes, launchpad would generate the necessary
recipe behind the scenes and use that to do the build.

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

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

>>> And we can't always know the package name from the branch
>>> either [1].)
>> 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?

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

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

> I'm also not sure how I'd edit a
> saved dailybuild something-other-than-recipe if I didn't have a
> concept of it being saved/available etc.

I don't understand how it follows that you wouldn't have a concept of it
being saved/available etc.

> But I'll try to organise a
> time to hear/discuss your thoughts on it! (or if you prefer to put
> theme here, that's fine too).

Sure thing.  I work 9-5 ET (14-22 UTC).

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAktsMgEACgkQ0F+nu1YWqI0KsACcCU87+dLjG7DS5xUY6OS/kPss
+WIAn2EUMqnHlfHzZDF3pZDupRYAUWZd
=ruda
-----END PGP SIGNATURE-----