Hallo, thanks for your suggestions. On Wednesday 16 August 2006 22:24, Robert Peterson wrote: > CVS keeps all back versions of the code, but it's not necessarily easy > to find a > subset that works with a given kernel, unless it happens to be the one > we're developing on. When do you decide to develop for a new kernel? Couldn't you store the code in your releases directory and tag it before you start programming for a new kernel version? In this case you will always have working releases for various kernel versions. > There's always the possibility of upgrading your kernel too. :7) I know and I agree :-) Unfortunately I am using a Xen kernel and standard Xen builds only against version 2.6.16. On Wednesday 16 August 2006 23:38, David Teigland wrote: > Look here: ftp://sources.redhat.com/pub/cluster/releases/ > > The latest release: cluster-1.02.00.tar.gz > builds against a standard 2.6.16 kernel. I will try to use this release and to build it against the 2.6.16 kernel. On Thursday 17 August 2006 01:17, Patton, Matthew F, CTR, OSD-PA&E wrote: > would it be too hard to start tagging releases? > > CVS Tag: 2.6.16-stable, or 2.6.16-dev, 2.6.18-dev > for example I agree. This would make it much easier to find the matching sources, especially for people who will download GFS for the first time (like me). Since a version of GFS is build against a special kernel version I was surprised that there is no identification of the source code (like the tagging that Matthew mentioned above). Thomas -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
