launchpad-dev team mailing list archive

[Michael Nelson <michael.nelson@xxxxxxxxxxxxx>]

On Tue, Feb 2, 2010 at 3:15 PM, Martin Albisetti <argentina@xxxxxxxxx> wrote:
> On Tue, Feb 2, 2010 at 10:01 AM, Michael Nelson
> <michael.nelson@xxxxxxxxxxxxx> wrote:
>> You can see the details at:
>>
>> https://dev.launchpad.net/BuildBranchToArchiveUI
>
> Hi Michael, this looks great. I've gone through the document and have
> a few questions to raise.

Great! Thanks for taking the time...

>
>
> General impressions:
> - In target user audiences, I wonder why you left out "Project
> maintainers". It seemed like one of the primary users for this.

I replaced "QA leads.." with Project maintainers.

> I'm
> also a bit confused as to whether the target audience is for "people
> who will use the feature" (the ones who will interact with the UI) or
> "people who will benefit from this feature" (this would just be people
> installing PPAs)

Yes, this work is primarily for the people who will be building
branches to archives. The UI for people just installing from targeted
PPAs won't change (although I'd *love* to take the opportunity to
update the PPA index to display installable binaries instead of a
'simplified' version of the list of source packages).

I'm not sure what the cause of confusion was?

> - Reading through this document ah brought back the itching need to
> link PPAs to projects. Many things would be much easier!
> - It seems to me from the UI, that I won't be able to easily say
> "build this every day in Lucid, Karmic, Jaunty and Hardy". I feel
> that's the way many people are using it today

Yes - it would be great to support this (with the improvements
suggested by James), but the current db schema and builder
implementation do not support multiple distroseries for a recipe or
multiple distroseries for a single build. I've created the following
bug to capture this:

https://bugs.edge.launchpad.net/launchpad-code/+bug/516448

On the other hand, the current schema and implementation *would*
support us creating four separate sourcepackagerecipebuilds for one
recipe (each with a different distroseries). So, it might be worth
weighing up the extra cost (building the same source package 4 times)
versus the benefit of supporting this straight away. Updated the
following bug with this info:

https://bugs.edge.launchpad.net/launchpad-code/+bug/513201


>
> Manual build of the latest branch revision:
> - I understand it as as a one-off action, I think we should show what
> specific revision you're building,

Yes, I've added a selector that defaults to (tip) - see if this is
what you had in mind.

> and maybe a link to it

Hrm, I think we should definitely link to the other branches mentioned
in the recipe - when not editing (I'd forgotten to do that), but the
base-branch is the current branch that you're viewing. Or did you mean
link to the specific version of the branch (ui-wise, that could be
tricky - perhaps a link next to the version selector? but it's already
very crowded.)


> - I wonder why the packaging branch isn't something you can search for
> and change. IIRC, there are some advanced use cases where you use more
> voodoo, but the common case would be marvelously simple if you would
> just select a packaging branch to create a recipe

I'm not sure how we could establish that link in the general case
(eg., I have a packaging branch in my +junk area?) But assuming that
it is possible, yes, the packaging branch could be a(n optional)
selector or inline branch picker.

This would mean that the text area would only be required for specific
recipes that merge multiple packaging/fix branches. Which leaves me
wondering whether we even should/need to convey the structure of the
actual recipe (ie. we could remove the uneditable header, and just
have a normal form with fields, rather than trying to emulate the
recipe text). We headed down this direction because there is no
standard way to construct a recipe and so I thought we'd need to
expose the recipe for what it was. But all of the above fields are
applicable to the various types of recipes (as long as the packaging
branch option is optional). As long as we always enable the text area
at the end so power users can add custom merge directives etc., we
should be able to cover the most common use-cases without exposing the
recipe?

I'll have a play with other layouts (after thinking more about James' points).

> - I'm not sure if "start build" is the right wording, as it may take
> hours to build  :)  Maybe just "Build"?

I've updated this as well.

> - When you expand the recipe, it seems as though you can edit it right
> there. There's may be some confusion involved in whether you're just
> editing it for that build, or editing the recipe all together

Sorry, that's my laziness in not creating a separate mockup. There was
never any intention that you would edit recipes on this form, only use
current recipes, or create a new recipe (as the focus is on building
the branch). I've updated the mockup to display three states
(collapsed, expanded to see recipe details, after clicking create new
recipe).

> - I'm not sure what the "# bzr-builder..." text is above the textarea

It's the standard header for recipes. As above, we were trying to
display the actual recipe text that would be created (due to all the
different ways recipes can be constructed), but it may be that we
don't need to do this...


> - The "Need help creating a recipe?" link would probably be useful in
> the unexpanded area

If we did lose the recipe structure on the form, this help would only
be necessary for people doing advanced things. Although we'd want a
separate link for help specifying the deb-version etc.

> - What's the UI for when I want to build but there are no recipes?  I
> imagined that will be the first experience for everybody, so we should
> really nail that

See the third dialog at:
http://people.canonical.com/~michaeln/bfb/build_now_overlay.png

>
> Daily builds:
> - I wonder if we could use a drop down instead of an expander with
> options like "Build revision XXX" and "Build daily"

Initially I balked at this thought, as it implies that a revision spec
should be on the SPRBuild table, rather than on the Recipe itself (as
part of the base_branch definition), but it does seem like a more
sensible place for a user to make the decision. And if we were able to
update the schema, it would provide much more re-usability to recipes.

What I mean is, if the "Build revision XXX" option specified the
base_branch revision on the recipe itself, the recipe would no longer
be re-usable (ie. I need a separate recipe the next time I want to
build a different rev, or tip). But, for this reason, perhaps it would
be better if the recipes created through the UI simply referred to tip
of the base-branch always (ie. no option there), and we added a
base_branch_revision_spec  column to the SourcePackageRecipeBuild
table? I've created

https://bugs.edge.launchpad.net/launchpad-code/+bug/516496

to track this.

Without updating the schema, I think putting the revision spec here
could be a source of confusion (I think I'm creating a general recipe
that I'll be able to re-use to build different revisions, but I'm
not).

>
>
> Phew, sorry it got long. I wanted to give a quick turnaround.
>

Thankyou * 1000 for such useful feedback!

>
> cheers,
> --
> Martin
>