Re: [kernel] r4732 - in dists: sid trunk

[Sven Luther <sven.luther@wanadoo.fr>]

On Sun, Nov 06, 2005 at 05:45:16PM -0700, dann frazier wrote:
> On Mon, 2005-11-07 at 00:23 +0100, Bastian Blank wrote:
> > On Sun, Nov 06, 2005 at 03:46:19PM -0700, dann frazier wrote:
> > >   Please stop with these unannounced (and seemingly arbitrary) moves.
> > > They add unnecessary confusion and I (and likely others) find it
> > > frustrating.
> > 
> > Hu? It disappeared without notice.
> 
> If I'd been working on the tree at the time, I probably would've whined
> then too.

I have another proposal, and it involves symlinks. Simon has shown that using
symlinks inside svn is fully supported by svn, so let's try that.

The plan goes as follows :

.../dists/versions/2.6.12
.../dists/versions/2.6.14
.../dists/versions/2.6.15-rcX
.../dists/versions/2.6.15
...
.../dists/versions/2.6-git

Which will hold the linux-2.6 dir, and will contain the whole stuff, we never
erase those, unless we remove the corresponding version from the archive, in
which case everyone will be happy and nobody should complain, since it would
have stabilized since some time. Notice that one of those versions will become
naturally the stable-security tree (do we realy need to keep two stable
branches, one for security and the other for normal updates ?), and is thus
not erased.

This is indeed similar to Dann's proposal, and will ensure everything is fine.
New branches are created from branching the latest tree, i.e., 2.6.15-rcX is
created from 2.6.14, and 2.6.15 is created from 2.6.15-rcX.

Now, the additional proposal is to have symlink in place, from
dists/etch/linux-2.6 and dists/sid/linux-2.6 and dists/exp/linux-2.6 to the
corresponding above versions, and a dists/trunk/linux-2.6 for the the tree
which would be the current one.

This should solve everyone's problem, i believe.

Notice that a more advanced fix here is to totally decouple the build
infrastructure from the actual versions. The version dependent part of our
packages are : 

  debian/changelog
  debian/arch
  debian/patches-debian
  debian/patches-arch

And all the rest is common, so we would have a per version copy of those 4
subdirs, and have a single copy of the infrastructure tree around.

Friendly,

Sven Luther