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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
