launchpad-dev team mailing list archive

[Aaron Bentley <aaron@xxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

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

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

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

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

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

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

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.

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

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4AsDgACgkQ0F+nu1YWqI0sUQCffH24UK3gP7BfAXmU7R+viq7o
y5kAnjAMQKmuzeGre31UcxC64KBQkrpu
=rm9/
-----END PGP SIGNATURE-----