launchpad-dev team mailing list archive

[Michael Nelson <michael.nelson@xxxxxxxxxxxxx>]

On Wed, Feb 3, 2010 at 9:58 PM, Aaron Bentley <aaron@xxxxxxxxxxxxx> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Michael Nelson wrote:
>>> The main point that underlies all my comemnts is that your focus is on
>>> "building a branch using a recipe," rather than "building a recipe."
>>
>> Yes, definitely. I had thought that the recipe is just a means to the
>> user goal of building a branch. Sorry, I wasn't trying to minimise
>> their importance or flexibility, but rather ensure that the desire "I
>> want to build this branch" stays in focus.
>
> So are we sure that building from a recipe should be a user-level thing
> at all?
>
> 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, by which
time, the concept of a "recipe" for your build makes sense (ie. you've
got a few ingredients). 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. And we can't always know the package name from the branch
either [1].)

And even if the above was feasible, we'd still need to create a recipe
to do the build, 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.

So I (personally) think that even new users need to be aware of
recipes (not only that they need to be aware, but that it's helpful
for them to be aware), but the simpler we can make the first
experience, the better. Let me know if you can see any holes in the
above argument.

-Michael

[1] But we could only display the package name field when we can't
determine it from the branch, that would reduce clutter too.