On Sun, 2010-12-12 at 19:52 +0100, Bastian Blank wrote: > Hi folks > > This is my proposal for a git-migration for the core Linux packages. I > believe it would work, but I have no implementation yet. It is more > complex than it would be with a fully merged tree, but it allows more > ways of doing development without needing to reinvent the wheel all the > time. Thanks for this. Comments inline below. > Please comment. > > Bastian > > ============ > Introduction > ============ > The Debian package for the Linux kernel and all related ones are > currently maintained by the kernel team in a Subversion repository. This > proofed as sometimes no easy way in the meantime. So the decision was > made to go for some git-centric source storage. > > This document describes my proposal of a setup that uses git with > submodules. It tries to support as much features of the current setup as > possible. Also it tries to support some new development usages that I > missed in the past. > > ============ > Repositories > ============ > The linux-2.6 package is built from several git repositories. This > repositories may be reused in other packages, like linux-tools-2.6. > In combination, this repositories includes anything to build the Debian > kernels and also derived variants. > > Repository "source" > =================== > This repository is derived from the upstream linux-2.6 and the upstream > stable repositories. It includes all the code for the main kernel > themself. > > Branches are used for the different supported versions. … > > Featureset can be included as different branches. While we don't have > any featuresets planned for Wheezy for the time beeing, I don't want to > loose the support for them. We do have some prospect of getting 'rt' and/or 'grsec' featuresets. I wonder what we should do when there are merge conflicts with a featureset. These are usually simple textual conflicts that can be resolved without deep understanding of the code, but a while ago there were some scheduler changes in a stable update that had to be deferred for OpenVZ and VServer until they were resolved upstream. How would we handle this in future? Would we have to defer applying the entire stable update for that featureset? > TODO > * Branch names Name like the current subdirectories of 'dists', except 'trunk' becomes 'master'. > * Architecture specific patches Architecture-specific patches are an anti-feature. The only such patches I see in etch, lenny or squeeze are the random changes from linux-m68k in lenny (if you don't think they're random, look at bugfix/m68k/2.6.26/m68k-remove-CVS-keywords.diff). I see no need to coddle architecture maintainers who don't want to cherry-pick the actually important fixes. (And using git makes it easy for maintainers of ports outside the main archive to maintain branches outside of our repository.) > Repository "config" > =================== > This repository includes the Debian config for the kernel images and > the helper packages. This corresponds to the current debian/config > directory in the package. > > The contents of this repository are loosly coupled with a specific > upstream version or patch level of the main source. > > Repository "infrastructure" > =========================== > This repository includes the infrastructure used to build the package. > This includes scripts for config handling, control templates, maintainer > scripts etc. The contents of this repository are declared independant of > the version of the source and the configs. This assumes we never need to make fixes to the packaging in a stable release, which is not true (think of reinstating LILO updates in lenny). > Repository "package" > ==================== > This repository pulls in the other three repositories as submodules. > > Layout: > Repository "source":: /source/$branch > Repository "infrastructure":: /debian > Repository "config":: /config > > Branches are used for different development trees. This includes the > trees for stable releases. This allows independant changes for all the > supported and unsupported versions. > > Tags are used for every release of the package. This tag also includes > references to all the commits of the submodules and therefor describes a > complete release without individual tags in all the repos. This allows > the user to retrieve all the informations to generate every version. > > ======================= > Source package handling > ======================= > The repository layout is way different from the current source package > layout and from the expectations by the Debian world. One nice way to > work with that is the "3.0 (custom)"[1] source type of dpkg. This type > is special and allows to script the source package generation and call > dpkg only with the finished set of files. The produced source package > will have a real type, most likely "3.0 (quilt)"[1]. > > This script would create anything a Debian source package needs. This > includes patches for every source from the base version. Also it may do > various safety checks like out-to-dateness of the several sources. Do you expect to create one patch for each commit in the 'source' repository from the base (or post-DFSG 'orig') version? It won't be possible to generate a linear series like this, in general. I expect to generate at most one patch for each stable update, one for all changes beyond that (other than featuresets), and one for each featureset. > ======================== > Advantages and Drawbacks > ======================== > Every submodule can be individual changed, updated or even replaced. > This allows the developer to remix different versions of the parts. > > Submodules needs to be updated explicitely. Submodules records the exact > commit in the parent repository. Every update of this commit list have > to be recorded by a seperate commit in the parent repository. Maybe we > can have some scripts to make the handling easier. > > A submodule reference does not keep objects alive. So without some extra > care, commits in the submodules may disappear. Doesn't that imply that the submodules should be tagged at the same time? Ben. > [1]: See dpkg-source(1) -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse.
Attachment:
signature.asc
Description: This is a digitally signed message part