On Sat, Oct 06, 2001 at 03:36:57PM +1200, Philip Charles wrote: > I have no feeling either way, but think that this is a good time to > examine the issue.
Well, we can only look at all the work that needs to be done, and if there are takers for all of it. Saying "we should release this at that time" is all very well, but there are very specific actions that need to be taken for a release to happen, and many of these actions can be started at any time, for example now or a few months ago. Most of them have not been started yet, or are stalled for a long time by now, and until most of the individual sub projects are running and mature, we can't say "let's release". If you need a list, Anthony posted a checklist for release-readyness some time ago, and in my reply I think I answered some points in more detail. For example, do you really want a release which has the Debian GNU/Linux makedev package in the archive? Getting rid of that requires changes in dpkg, apt, dinstall and all other packaging tools out there. And this work has not started yet. In fact, it is not even discussed and decided how to go about it. I hope nobody gets me wrong. I don't want to discourage a release at any specific time or in any particular way. But it is important that people who want to see the Hurd released at some time and can help, start to work on it now. They should not wait for any decision on how and when and in which way the release will be happen. You started to make CD images without waiting for us to decide that we want CD images for the release at point XYZ, and that's the sort of initiative we need to see in other areas as well before I can feel comfortably about a release. What I want to say is that a release emerges out of many efforts to get the software in a releasable state. Putting the horse before the cart doesn't sound too useful to me. > Keep the source and binary packages that the Hurd wants in pool. After > all pool contains sid, woody and potato at the moment. Why not Woden (or > some-such) as well? Theoretically, this is possible. Practically, you always have to make the decision if you update a package or not, and if you update it to get a bug fix, the usual experience is that if you include a package newer than the rest of the distribution, many other packages have to be updated as well (like in, foo sucks in a new glibc, and this sucks in a new version of about twenty other packages). I understand how splitting off the Hurd distribution can be achieved technically, but I don't think it is feasible for us. > > 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. > > Agreed. I have mainly seen this in boot-floppies and debian-cd. The > strife these teams have with a specific arch at times. Would it not be > easier for them to get GNU/Linux out of the way and then sort out > GNU/Hurd? The same tools could be updated for any subsiquent Hurd > release. The question is, would they do it? > > 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). > > Am I right in thinking that this is a problem specific to the Hurd? I don't understand your question. It is a question specific to Debian GNU/Hurd, or to GNU/Hurd if you want. The code for POSIX threads has all to be in glibc and the Hurd, but the binary compatibility is only of concern for Debian. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
