launchpad-dev team mailing list archive

[Michael Nelson <michael.nelson@xxxxxxxxxxxxx>]

On Tue, Feb 2, 2010 at 8:52 PM, James Westby <jw+debian@xxxxxxxxxxxxxxx> wrote:
> On Tue, 2 Feb 2010 11:01:49 +0100, Michael Nelson <michael.nelson@xxxxxxxxxxxxx> wrote:
>> Hi all,
>>
>> I've been putting together some mockups for the build-from-branch UI
>> work (with the help of jml, wgrant and mwhudson), and would love to
>> hear ideas on how they could be improved or re-worked etc.
>>
>> You can see the details at:
>>
>> https://dev.launchpad.net/BuildBranchToArchiveUI
>
> Thanks for working on this Michael, it's great to be able to review it
> as a whole at this time, rather than making comments as the changes
> arrive.

It's a pleasure... and it's great finding lots of issues before any UI
code has been written too :), so thanks for all your input!

>
> I have some comments that are quite fundamental, but let me say first
> that I like the design for interaction, and I'm confident that whatever
> you end up going with will be a pleasure to use.
>
> 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.

>
> I think that it is important to have something on a branch page to get
> started, but I'm not sure that driving everything from the point of view
> of the branch is the right thing to do.

Yes, I agree that the (base?) branch shoudn't be the starting point
for every recipe-related action, but I'm not sure if I'm understanding
all of what you're saying. For example, there are urls along the lines
of (from the wiki page):

(code?) ~owner/distro/distroseries/sourcepackagename/recipename
(code?) ~owner/+recipes: all recipes owned/created by a person

as points for viewing/editing and dealing with recipes directly.

> For instance, I might go to the
> branch page for the packaging branch, and want to do a build from there,

Why wouldn't this be possible? Given that if you click "Build this
branch" (or whatever it'll be), the overlay will allow you to select
the recipe you want (ie. including those recipes that just refer to
this branch).

> but for daily builds that won't be the base branch.

Yes, so if, from the packaging branch, you click on "Build this
branch" and non of the available recipes meet your requirements, so
you need to create a new recipe - then if you do want a base-branch
different from the current one you're stuck at this point (with the
current design, as the base-branch is non-editable).

So I talked with jml about this the other day when thinking through
the workflow, and from memory there were three thoughts:

1. The base-branch seems like the logical place to build your
base-branch (and specifying the packaging branch from there). That's
not to say it is the only way, just the most natural way for the 90%
case. Do you have other thoughts?
2. we couldn't see how we could have a consistent UI if users
specified the base-branch (as you could create a recipe that has
nothing to do with the current branch at all. [1])
3. The case where it *does* make sense to initiate the recipe creation
from a packaging branch is when the packaging branch contains the
source already, and hence it is the base_branch (ie. no other merges
required to have both the debian directory and the source code
toghether). I guess you are saying that there are other cases?

[1] That's not to say that the base-branch shouldn't be editable when
you edit the recipe itself, as the recipe's traversal is not
restricted by the branch:
~owner/distro/distroseries/sourcepackagename/recipename/+edit

Given that you understand the workflows much better than anyone, I'd
be keen to have a call sometime to clarify the above :)

>
> If I were to make a suggestion it may be for the following:
>
>  * A branch page has a list of recipes that mention the branch, and
>    a link to add a new one.

This is exactly what's displayed in the overlay isn't it (or the
non-js version)? It would be difficult to display this information
(the recipes) on the branch page itself, as there is no single bit of
the recipe that helps users identify whether it's the one they're
after. You'd need the recipe name, owner, (distroseries?), at the very
least (hence that's what's displayed in the overlay dropdown, but even
then you might need more information (revnos, packaging branch etc.),
which is why the overlay displays that in-line.

>  * You can navigate to the +recipe page from there, and from there
>    there is a "build this" button, which launches the archive picker.

So as mentioned that navigation step would only be necessary if the
recipe details were not present on the page where you select the
recipe (ie. if you just listed the recipe names (?) on the branch page
as you mentioned). But this would potentially be a lot of
back-and-forward to find the recipe that suites your needs?

It would certainly be possible to include a link on the overlay to the
actual recipe (perhaps to edit the recipe if applicable, as that's not
possible from the overlay), but I'm not sure what benefit there is
otherwise, given that all the recipe details can be presented there
(when requested)?

>
> It's extra clicks I think, but it makes recipes more of a first-class
> object, rather than trying to make them an implementation detail, which
> is what your layout feels like.

Yes, I guess the layout does feel like that - the recipe is a way to
specify the right combination of branches (and potentially other
instructions) so that I can build this branch to my PPA. I think the
recipes are a first-class object (amazingly general and powerful)! And
the API will expose all of that, but I'm not sure that the web UI
should. I mean, at one end of the spectrum we could present a
free-form text-area in the web UI to give users all the power (this
will be possible via the API), and at the other end only allow
specifying very few details, and I guess we're just trying to find the
right balance.


> This isn't just me wanting my work to be
> front and center :-). The recipe can be more than just a pointer to the
> packaging branch.

Yeah, I'm pretty amazed at what they can do!

>
> I would be anxious for people that don't really care to get something
> that works as quickly as possible though.

Yep, me too.

>
> Some further unstructured comments:
>
>  "When viewing a source package recipe build within their PPA, users
>  can:" easily go to the recipe that was used and from there to the
>  branches. They should also be able to go to the manifest and so see
>  the revisions that were used. I'm keen for these links to be more
>  common in Launchpad, from e.g. bugs to the revisions that fix them
>  etc. Being able to go binary package->source package->manifest->
>  branches will be useful.

Yes, that's great. I've updated the wiki with:
When viewing a source package recipe build within their PPA, users can:
...
 * View the manifest (and from there the related branches and recipe)

Although it'd be worth a link from the manifest to the recipe, I
wouldn't link directly to the recipe as it could be very confusing if
the recipe has been edited since?

>
>  Having the recipe editable from the recipe selector seems a little odd
>  to me. Reducing the rounds trips would be good, but it may confuse
>  some people who don't realise they are editing a shared object.

Yes, the mockup wasn't meant to communicate that it was editable (just
that you could create a new recipe) - my mistake. I've updated it to
show the non-editable recipe selection/display. See what you think.

> Given
>  that they are series-specific this won't cause too many problems in
>  practice though I expect.

Well, hopefully the recipe itself won't be series specific as it
sounds like that's a strong use-case (I created bug 516448 based on
your and Martin's input, and I'll add it to the use-cases).

>
>  "Should a recipe handle all distro series?!" - If we are going to do
>  this then why bother building the source package on each release?
>  Build the source once and then rebuild it tweaking the binary package
>  version? It may be slightly more work to go from a branch that can
>  build a source package for each release and a branch that can build a
>  source package that can be built on each release (small difference).
>  Would be a great feature to have, but I'm not sure that it's the right
>  place to implement it.

So yes, we could support the less efficient SPRBuild per distroseries
now (if I put back the distroseries argument in the newBuild() method
of yours :) )., but your idea would be much better (hence the new
bug).

I'm not sure what you meant by "but I'm not sure that it's the right
place to implement it." (place as in time, or location?). If you get a
chance, can you clarify on the bug? Thanks!
https://bugs.edge.launchpad.net/launchpad-code/+bug/516448

>
>  "Slow moving projects, duplicate rejects" either do what Aaron
>  suggests, or provide the manifest to the buildd (which I want to do
>  anyway), and use the mode where if the recipe resolves to the same
>  revisions from the same branches as last time it wont build.

I'm not sure it would even need to go as far as the buildd - we'll
have the previous manifest in the DB, so as long as we create the
manifest first (ah, right, that's what you're saying), we can compare
it with the previous build of the same recipe in that archive.

So yes, I agree that it'd be great to send manifests to the buildd
rather than recipes (as it guarantees what will be produced), and I
assume we can do this as the only missing information would be the tip
revision which we have in the db (IBranch.last_mirrored_id?),
although, are other calculated revisionspec's allowed for branches in
a recipe? (ie. last:3) If so, then I guess we can't calculate the
manifest to send to the buildd?

Maybe Michael H. can confirm? If it is something we can do, I'll
create a bug for it too.


>
>  "Do we currently detect when *none* of the branches associated with a
>  recipe add a debian directory?" We could add a better error message to
>  bzr-builder so that when they get the build failure email they will
>  know what to do.

That'd be great.

>
>  "I'm assuming that part of our validation when creating a build should
>  be that the evaluated deb-version will be greater than all current
>  versions in the target PPA?" I'm not sure we can do that?

Do you mean you're not sure that we could calculate the dev version
from the recipe on LP? As I think if we can do that we could easily
find the last SPPH for that source package in the archive/distroseries
and compare the versions?

>
>  "The destination target needs a progress indicator. For PPAs, the
>  detail packages page should show the source package in the
>  construction (builddeb) phase, which conceptually is before anything
>  it shows right now. How will we do this?" I think adding a line,
>  perhaps with a different background, and with (building) or something
>  added, but only in the maintainer's view of the PPA.
>
> Thanks,
>

Thanks for all the thoughts and input James. I'd like to organise a
call sometime so I can better understand your main concern regarding
how the recipe should be used in the UI.

> James
>