On Sat, Oct 06, 2001 at 01:47:46PM +1200, Philip Charles wrote: > I can see a number of advantages in having separate release dates, version > numbers and names for the Hurd releases.
There is a big fat disadvantage, and that is that we share 99.99% of the packages, and it's old Debian tradition to break second package from the time of a release to shortly before the next release. Getting a release together while Debian changes under your feet will be considerably harder than if you just step in measure with the masses. The other disadvantage is that you have to duplicate the complete release. A release is a lot of work, so much work, that it usually burns at least one person entirely on the way. I would like to avoid that if at all possible and have as much of the common work done by Debian people (both, GNU/Linux and GNU/Hurd) rather than by us alone. A release comes with many strings attached (for example, it's also a strong commitment on upgradeability, and a commitment for extensive testing cycles and newbie help). I don't want to rule out that we do some sort of intermediate release between woody and woody+1, but I don't see it currently within my sight. It depends on too many factors I can't calculate (ideally, I would break binary compatibility of glibc before we do the first real release, and do it only once. This means we need to get POSIX threads in shape. This is just an example, but it's certainly the thing that bothers me most). > This could be a problem as new architectures are added to the Hurd > and are ready before the next release of GNU/Linux is due. We can worry about this if/when it happens. Your reasons are all very well, but I am not sure you have taken into consideration the amount of work to be done and who will do it if we cut ourselve out of the general release cycle. Here is an idea: We try as good as possible to catch up with the Debian GNU/Linux folks in the upcoming woody release, and use that experience to see how good we can cope with the involved issues. Sort of a test run. Thanks, Marcus
