launchpad-dev team mailing list archive

[Jelmer Vernooij <jelmer@xxxxxxxxxxxxx>]

On Tue, 2011-06-21 at 10:52 -0400, Aaron Bentley wrote:
> On 11-06-20 05:17 PM, Jelmer Vernooij wrote:
> > On 06/20/2011 10:12 PM, Aaron Bentley wrote:
> >> On 11-06-20 03:32 PM, Jelmer Vernooij wrote:
> You asked for feedback, though, and my feedback is that it doesn't make
> a strong case for BuildFromBranch as separate functionality from
> BuildFromRecipe.  Adding the arguments from your email would definitely
> strengthen it.
I do appreciate the feedback and I'll to update the LEP based on our
discussion.

> > I don't agree that doing a one-off build of a branch from a recipe is
> > trivial. You have to create a recipe, select a PPA, request a build, and
> > then delete the recipe after the build has completed.
> I meant that it was functionally trivial.  I agree that the UI could be
> improved, but bad UI isn't a good case for new functionality.

> I certainly wouldn't want to have to go
> > through this every time I do an upload to Ubuntu or a PPA.
> That's a UI thing, not a functionality thing.
I agree it is functionally trivial, and most of the work is in the UI.
Compared to most of the LEPs currently listed it will probably take a
lot less time to implement. That doesn't mean it is not appropriate for
a LEP.

> > Recipes don't
> > allow you to build a specific revision in a branch as-is, they always
> > add a custom changelog entry.
> True.  One solution would be to enable this in bzr-builder.
This has actually been fixed in bzr-builder - deb-version is now
optional and if it's not specified it won't add a changelog entry. The
way Launchpad uses it doesn't actually allow you to use it this way though.

> > Recipes are very useful for doing regular builds from a combination of
> > multiple branches into a PPA (like daily builds). They're less
> > appropriate for manual builds into an archive.
> ISTM that the only thing that makes recipes inappropriate for manual
> builds into archives is the inability to build a specific revision in a
> branch as-is.  Are there other functional issues?
It is possible to build a specific revision if you want to, you can
specify one in the recipe, like so:

# bzr-builder format 0.4
ubuntu:iprint 3

to build revno 3 of ubuntu:iprint

> >> I don't understand this:
> >>
> >>    It seems like locking the source package branch to the branch makes
> >>    it easier to find the right source for a package, and easier to get
> >>    the right access control.
> >>
> >> It seems like you're assuming recipes are stored as text, but they're
> >> not.  They provide foreign key references to branches.  So it's very
> >> easy to find the right source for a package.
> > I realize they're not stored as text, but that does not necessarily make
> > it trivial to find the relevant distributionsourcepackage. There may be
> > multiple packaging branches in a recipe.
> 
> There will be only one branch in a single-branch recipe, and even in a
> multiple-branch recipe, the base_branch is special.
Still - it will be harder to e.g. write a query that returns all source
package releases built from the last X revisions in a branch.

> > Finding the right access control isn't necessary for this particular
> > LEP, but will matter for BuildFromBranchIntoPrimary.
> And you would never want to build from recipe into primary?
I don't think you would, certainly not from branches that
non-ubuntu-committers have direct write access to.

There might be some odd cases where you would want to build using a
recipe, but I can't really think of any at the moment. It certainly
won't be a common case.

> >>    We can generate manifests on demand from a SourcePackageBranchBuild
> >>    if users need them, there's no need to store them in the database
> >> Manifests provide traceability, like logs.  Users may not know they need
> >> them until days or weeks after they've performed the build.
> > For the trivial case (a single revision from a branch) the manifest only
> > contains the root branch and the revision id that was built. I don't see
> > the benefit in storing that information in a complex form in the
> > database.
> That seems like a different argument.  Perhaps they are complex, but
> that has nothing to do with the need for traceability.
> 
> It would be sub-optimal to have two different ways of determining the
> built revision.
I don't see how manifests really provide traceability - the only thing
they know is what revision from what branch was built. If we keep track
of that data in another manner anyway, how do manifests help with traceability? 

Most of the interesting traced data is either in the build logs, or in
the build table anyway (requester of the build, target archive, etc).

> > For example, this is what the manifest looks like for a single
> > branch build of ubuntu:iprint:
> > 
> > {{{
> > # bzr-builder format 0.4
> > ubuntu:iprint revid:james.westby@xxxxxxxxxx-20061024192147-kbnxs2004h4b0lfc
> > }}}
> > 
> > We would already have to store these two attributes as part of the build
> > anyway, as we need to track what the user wants built.
> So the recipe could be its own manifest, then.

> > Most of the code would be shared.
> To me, it looks like new code in the buildd, new code in the UI, new
> database tables.  We use recipes to link everything together, so
> eliminating recipes means a lot of rewriting.
The recipe and manifest only complicate matters here - they
aren't necessary for bzr-builder to be able to build from a branch.
What benefit would having a recipe have here?

Hiding recipes at the UI layer for build-from-branch builds is going to
make things more complicated. Recipes make it
harder to find back the relevant revision and branch that the build was
created from. Manifests don't add extra traceability.

> The user model impact is also significant.  It means one more feature of
> Launchpad for users to keep track of.  They would need to understand the
> differences between the two kinds of source builds, and have to decide
> which was appropriate in which circumstances.
That's a good point, though that question would also apply to building
from a branch into the primary archive. 

Cheers,

Jelmer

Attachment: signature.asc
Description: This is a digitally signed message part