launchpad-dev team mailing list archive

[James Westby <jw+debian@xxxxxxxxxxxxxxx>]

Hi,

Thanks for working on this everyone.

Apologies if I duplicate comments already made elsewhere in the thread.

On Wed Nov 18 00:15:27 -0600 2009 Michael Hudson wrote:
> Separately, we need to decide where a recipe lives.  The current
> thinking is
> "https://launchpad.net/ubuntu/karmic/+source/some-package/+recipe/recipe-name";
> which seems OK to me (we'd have to trust a bit that this recipe would
> build a recipe for some-package in karmic, but that doesn't seem any
> different to say branches today).

Why not under a person? How do you do access control?

> Finally, we could stick an archive on the recipe, but maybe we don't
> want to.  I'll talk about this a bit more later in the mail.

I don't think we want to. They are not archive-specific, and you could
put the recipe in to any archive.

However, knowing which recipe was used to build a package would be
useful.

> One of the things bzr-builder does when it creates the debianised source
> tree is create a manifest, which is a sort of frozen version of a recipe
> -- it references particular revisions of the branches so as to allow a
> repeat of exactly this build.  We could use a manifest like this to
> actually run the recipe: at the point where the build is requested, we
> make the manifest and stuff it into the database.  This seems like a
> neat idea, but isn't how bzr-builder works now as far as I can tell.

It's not. However, I think it's quite a good idea, otherwise you
have to collect the manifest too, or have the collector extract it
from the source package.

The difficulty would be resolving revision ids, as that requires bzr
code, rather than just SQL (I assume).

> I think the current plan is to use bzr-builder to make the debianized
> source tree and bzr-builddeb to then make the source package.

That currently isn't possible, but we plan to fix that. This may be
the preferred way, but we need to decide how they will work together
to be sure.

> I'm
> presume the process for getting the source package off the builder and
> into the process of being built will follow that of the existing
> builders: the builder will tell the buildd-manager where to get the
> .dsc, the manager will parse this to find the other parts of the package
> and then grab them, shove all of the files into the librarian and
> trigger the existing parts of soyuz to look at them somehow[1].

Will tell it where the .changes is, no? Also, as I said, you may
have to collect a manifest as well.

> In case the above wasn't enough, here's some things I haven't thought
> hard about:
> 
>  - do people want to subscribe to a recipe?
>    - does this mean getting notified when the recipe builds or fails to
>      build?
>    - does this mean getting notified when the recipe is changed?

This is very important to get right. I don't know whether subscription
is the right approach, but notifications on problems need to be communicated
to the right people in the right way.

Thanks,

James