launchpad-dev team mailing list archive

[Michael Hudson <michael.hudson@xxxxxxxxxxxxx>]

James Westby wrote:
> 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?

Recipes would definitely have an owner for access control.  Whether that
would be part of the URL/namespace is a separate decision.

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

Right.

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

Hm.  At least making the manifest doesn't require running arbitrary code :-)

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

OK, I'll apply a thin SEP[1] film to this issue then for now.  It's
certainly independent from how we model this in the database.

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

Er, maybe.  My brain refuses to remember all these debian details :)

> Also, as I said, you may
> have to collect a manifest as well.

Right.  I think the existing soyuz code is fairly flexible in this regard.

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

OK.

> 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 for the clear specification :-)

Cheers,
mwh

[1] SEP == someone else's problem, in case anyone hasn't read the
hitchiker's guide to the galaxy books.