launchpad-dev team mailing list archive

[Dmitrijs Ledkovs <dmitrij.ledkov@xxxxxxxxx>]

On 3 February 2010 20:58, Aaron Bentley <aaron@xxxxxxxxxxxxx> wrote:
> 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?
>
> Aaron

IMHO it would be 50/50 split cause I'm still thinking in terms of
packaging branch as the starting point and which branches do I want to
build using it. For example as an upstream project maintainer I will
strive to minimize amount of packaging branches / recipes cause that's
not usually upstream expertise. So I would have one packaging branch
possibly pinched of ubuntu and then I will go to it and start thinking
which of my project branches I want to build eg. stable release,
supported release and this wacky hack I'm working on. And ooops hardy
has different lib sonames so i need to use this other packaging branch
cause it has build time patch. So again I would go to hardy packaging
branch and say oh yeah do just the stable branch cause I really don't
want anyone to develop latest features with out-of-date libs for
example.

This feature will be a popular both from Ubuntu development side and
the upstream projects using launchpad for project management, QA /
ubuntu experience enhancement.

-- 
With best regards


Dmitrijs Ledkovs (for short Dima),
Ледков Дмитрий Юрьевич

()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments