Re: The Hurd release policy. Was Will the hurd go into woody ?
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 brinkmd@debian.org
Marcus Brinkmann GNU http://www.gnu.org marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de
Reply to: