launchpad-dev team mailing list archive

[Jelmer Vernooij <jelmer@xxxxxxxxxxxxx>]

On 06/20/2011 10:12 PM, Aaron Bentley wrote:
> On 11-06-20 03:32 PM, Jelmer Vernooij wrote:
> > Hi Launchpadders,
> >
> > I would be interested to hear feedback on
> > https://dev.launchpad.net/LEP/BuildFromBranchIntoArchive
> It's surprising to see this LEP.  Considering that we support recipes,
> and building from a branch is a trivial case of building from a recipe,
> it seemed natural to do it that way.  In fact, we you create a recipe,
> you get a default recipe that builds from a branch.
>
> I would like a much more thorough explanation of:
>
>    Using recipes as they currently exist may make the linkage between
>    source package branch and built source package much looser.
This LEP is mostly a subset of the (already approved) 
BuildFromBranchIntoPrimary LEP.

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. Recipes don't 
allow you to build a specific revision in a branch as-is, they always 
add a custom changelog entry. I certainly wouldn't want to have to go 
through this every time I do an upload to Ubuntu or a PPA.

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.

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

Finding the right access control isn't necessary for this particular 
LEP, but will matter for BuildFromBranchIntoPrimary.

> I disagree with this:
>
>    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. 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.

bzr-builder still provides a testament if you build directly from a 
branch, and we can compare that testament to the data in the database.

> - From the LEP, it's not clear that the benefits are valuable enough to
> justify having two ways of doing basically the same thing.
Most of the code would be shared. This LEP proposes (roughly) a new 
SourcePackageBranchBuild (with a branch and a revid attribute rather 
than recipe attribute), a SourcePackageBranchBuildJob and some UI bits.

Cheers,

Jelmer