← Back to team overview

launchpad-dev team mailing list archive

Re: Build from recipes to multiple series


On Tue, Mar 2, 2010 at 2:16 PM, Jonathan Lange <jml@xxxxxxxxxxxxx> wrote:
> On Tue, Mar 2, 2010 at 12:52 PM, James Westby <jw+debian@xxxxxxxxxxxxxxx> wrote:
>> On Tue, 2 Mar 2010 12:36:28 +0000, Jonathan Lange <jml@xxxxxxxxxxxxx> wrote:
>>> >> There are open questions about how it matches with some UI issues, and
>>> >> how we store the recipes given the fact that they aren't necessarily
>>> >> tied to a single series.
>>> >>
>>> Storage should be guided by the UI, not the other way around.
>> Indeed, what I meant was:
>>  traversal needs to be considered, as the current plan falls down to
>>  some extent if a recipe doesn't have a single target series. In
>>  addition there are open UI questions about which recipe to present to
>>  the user given that the current mockups lead them to choose the recipe
>>  before selecting target distroseries. If they are looking at a
>>  packaging branch then we can key of that, but even then do you show
>>  all recipes that have been used to build for that series? Only those
>>  that had a successful build? What do you show if none have been built
>>  for the series yet (e.g. the day after we release lucid and open m***)
> All good questions :)
> I reckon Tim or Michael N will be able to answer those more quickly
> and more clearly than I.

Hi Jonathan, I've just been on the phone with James checking through
these questions, and he's happy with the way the current mockups deal
with choosing distroseries etc. (as in a recipe can support multiple
distroseries, and these are presented when selecting the recipe as
shown at: https://dev.launchpad.net/BuildBranchToArchiveUI/UseCaseManualBuild

He needs more of an official, "yes, this is what we want to support,
go ahead and start coding" from the relevant person.

He does have an extra feature that he'd like to see (not in the
initial cut), in that, if the branch where the interaction begins is
in the packaging branch name-space (ie. we know it contains debian
packaging and we know the distroseries) that either (1) users would
not be required to create a recipe (a "Default build using debian
packaging"-or-similar option would be present, with the recipe created
when they build), or (2) clicking on the Create a new recipe would
pre-fill all the relevant description/name etc., so they just have to
save it.

Jame's will have more of a think about which option would be more
useful (ie. ease-of-initial-use vs. getting devs used to the concept
of recipes), and I'll add a use-case to the wiki for this so it isn't


> ...
>>>  * It looks like it has the potential to be very confusing
>> Could you be a little more verbose?
> A derived recipe isn't designed for readability. To understand what it
> means, you need to be able to look at the parent recipes. The
> difference between "insert-after" and "insert-nest" causes me to pause
> and think when I read them. All of these combined make me think that
> derived recipes can confuse newbies.
> I think it's pretty much inherent to derivation though.
>>>  * Why not "remove"?
>> If you aint gonna need it...
> OK, you've convinced me. Let's wait for a use case :)
>>> What's the next step?
>> I need to know that the proposals here allow for the desired UI to be
>> implemented, and we need a decision on the two options in the
>> multi-series proposal.
>> Once we have something that works well for the user experience I can
>> implement it or help someone else through the process.
>> I will be waiting on confirmation from the LP team on what they would
>> like to have, preferably with (updated) mockups that outline how they
>> will map to the new features.
> OK. I don't have an opinion now, but will cultivate one carefully over
> the next few hours.
> jml
> _______________________________________________
> Mailing list: https://launchpad.net/~launchpad-dev
> Post to     : launchpad-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~launchpad-dev
> More help   : https://help.launchpad.net/ListHelp