launchpad-dev team mailing list archive

[James Westby <jw+debian@xxxxxxxxxxxxxxx>]

On Wed, 3 Feb 2010 16:12:10 +0100, Michael Nelson <michael.nelson@xxxxxxxxxxxxx> wrote:
> > 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 agree that is an important aim.

> 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).

That wasn't clear, sorry. I think the base branch being immutable in the
overlay indicated to me that it was all that would be offered.

> > 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?

I think it may be skewed as I am an Ubuntu developer, but I don't think
packaging branches will just be implementation details.

For instance, you may decide you want to set up a daily build for a new
project, which isn't packaged yet. To do this you branch, create the
packaging and push it. They you may go to the packaging branch as that
was just what you were working with.

I'm not sure it's a good enough argument that it should change your
approach, but perhaps something like giving them a message if they
choose daily build while on a package branch.

> 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?

Well, creating a recipe from a packaging branch is how you will build a
package in a non-daily fashion, so that has to be supported, but it will
be the base branch in that case.

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

I'd be happy to do that. Next week is probably better as I guess we will
be in closer timezones again.

> 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.

Makes sense.

[ snip more convincing comments ]

> > 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?

Good point.

> 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.

Looks great.

> 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

Location for the feature I guess, meaning that the more general solution
would be better in my eyes.

> >  "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.

It's not clear at this point whether the manifest can be created outside
the buildd.

I want the previous manifest anyway for a feature I plan to add to have
the changelog include more information about what changed.

> 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?

Yes they are supported, which makes it tricky. If "run" is supported
then it has to be on the buildd.

> That'd be great.

Please file a bug on bzr-builder.

> >  "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?

Yes, that's what I mean. See above about the manifest, with the further
complication that the version can now depend on the contents of the tree.

> 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.

Let's do that.

Thanks,

James