On Sun, 2008-11-30 at 19:23 +0100, Stefano Zacchiroli wrote: > On Fri, Nov 28, 2008 at 04:10:35PM +0000, James Westby wrote: > > In my opinion it doesn't prejudice the aims of vcs-pkg at all. > > Agreed. Rather, it accounts for an experiment at which we should look > with interest. > > In particular, logs are important, for example I'd be curious to know > how much the typical access path to your sources (presumably "apt-get > source", but maybe even the website, or whatever else) will change > with this.
I'm not sure what you mean here, could you clarify? > More generally, I've a handful of other questions on the > infrastructure: > > - is the source code of the infrastructure available? (sorry, I'm > writing off-line and I can't check by myself) The logic is in bzr-builddeb. There are some scripts that run that in a loop after checking what versions of a package haven't been imported after grabbing that information to launchpad which are not in the branch. http://code.launchpad.net/bzr-builddeb > - how tied is the infrastructure to bzr? would it make sense to have > different back-ends (well, front-ends for the final users) for the > various DVCS? It's pretty tied to bzr currently, but the ideas don't require bzr. You could implement different back-ends, but I don't have a desire to, and I'm not sure it would be a good idea. > The question is of course modulo the usual problems of > synchronization between different VCS, but note that those problems > do not pop up for packages which are _not_ regularly maintained > using VCS, but are rather just injected regularly into bzr Yeah, for things maintained in VCS we plan to suck the packaging directly in to bzr and use that, we've just focused on the general case first. There are some difficulties though. For instance we want full source branches, and a lot of SVN packaging is mergeWithUpstream style, so we will have to put it back together again while still making it useful for collaboration. We also need to handle the probably hundreds of tagging schemes out there to be able to tag the historic releases appropriately. (We tag every release with a specific naming scheme so that the tools can rely on that being there) > - how specific to Ubuntu is the infrastructure? Would it be possible / > easy to set up the very same service for Debian or for any other > Debian derivative? The UDS session I linked to is about this. This cycle I am going to be working on bringing up an import of Debian to bzr with shared revision history and all the merges represented as multi-parent commits. The code is actually there now (it attempts to detect merges from e.g. "intrepid-security" to "intrepid-updates"), but we felt just bringing up Ubuntu was enough work for the first step. These branches will be hosted on launchpad as well, under the "/debian/" namespace. They will be read-only, but will be there for any Debian developer to use if they like. I haven't discussed this much with the launchpad team yet, but it may be possible for a package maintainer to get write access to the branch if they liked. One thing that is going to hamper us is that we don't have historic packages for Debian. I'm interested to know if the official version of "snapshot.debian.net" will have all the old packages, which would be a massive help for us. If not then we may end up with the bzr branches suggesting that Debian was branched off Ubuntu :-) If any interested Debian people can make it to UDS in SF next week then your input in to the above discussion would be appreciated. We have a few DDs invited, and plenty of DDs within Ubuntu anyway, so that perspective will be represented, but having any specifically interested in this topic would be great. Thanks, James _______________________________________________ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss