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