launchpad-dev team mailing list archive

[Michael Nelson <michael.nelson@xxxxxxxxxxxxx>]

On Thu, Feb 4, 2010 at 7:06 PM, Aaron Bentley <aaron@xxxxxxxxxxxxx> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Michael Nelson wrote:
>> On Wed, Feb 3, 2010 at 9:58 PM, Aaron Bentley <aaron@xxxxxxxxxxxxx> wrote:
>>> It seems like a major use case will be "build this branch using this
>>> packaging branch".  If we had a UI that just provided that, what
>>> percentage of our users would still need more?
>>
>> I think people need (and want) more than just the packaging branch.
>> For example, they'd want to specify the distroseries as well
>
> 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 haven't yet added any mockups showing this. I'll try to do this today.

> If so, our UI should let them choose a list of distroseries
> and create as many recipes as necessary behind the scenes.
>
>> by which
>> time, the concept of a "recipe" for your build makes sense (ie. you've
>> got a few ingredients).
>
> 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.

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

Of course, we could instead just present by default the last
information entered by the user, but this would obviously not always
work.

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

>
>> On top of that, I don't see how we can guess a
>> valid deb version (as it depends on what's been uploaded to the PPA
>> before etc.
>
> Surely we know what's been uploaded to a PPA before?  Anyhow, that's a
> domain-specific thing, not necessarily a recipe thing.

Yes we know what's been uploaded before (sorry, I should have
qualified that), but that doesn't help us to specify a *re-usable* deb
version string like "1.0+{revno}-{revno:packaging}" (which we can't
necessarily evaluate)

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.

I might try to organise a time to call and talk more about that. I'm
still not sure how that would allow us to guess a valid deb_version
for a single build (that is, incrementing the latest version published
in the PPA might not be what you want). But maybe there is a way to do
this in a sane way?

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

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 The
canonical traversal for displaying/editing a recipe.

Maybe that needs to be re-thought? Or those who made that decision
might be able to comment. As currently this could lead to users
unintentionally changing the sourcepackagename from what's specified
in the packaging branches changelog.

Without this, we could certainly drop the *requirement* for the
sourcepackage name when creating a build/recipe. At the moment the
best we can do is hide the field when we already know the source
package name (via the product series packaging entry?).

(Of course, although it doesn't need to be required, it should still
be available as it is an option that we can pass through to dailydeb
to *override* the value in the changes file.)

>
>> And even if the above was feasible, we'd still need to create a recipe
>> to do the build
>
> Absolutely.  I never meant to suggest otherwise.
>
>> and so when the same user comes back next time to
>> build that branch again, we'd want to give them the option of
>> selecting their previous recipe rather than silently creating another
>> one.
>
> 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). 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. 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).

Thanks!