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. _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
