[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

The Hurd release policy. Was Will the hurd go into woody ?



I have no feeling either way, but think that this is a good time to
examine the issue.

The Devil's Advocate continues.

On Sat, 6 Oct 2001, Marcus Brinkmann wrote:

> 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.

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?

> 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.

> 
> 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?

> 
> > 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.

And what the Devil's Advocate suggests is, if it goes well, release.

Phil.

-
  Philip Charles; 39a Paterson St., Dunedin, New Zealand; +64 3 4882818
Mobile 025 267 9420.  I sell GNU/Linux CDs.   See http://www.copyleft.co.nz
     philipc@copyleft.co.nz - preferred.           philipc@debian.org



Reply to: