[Top][All Lists]

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

Re: Moving to git

From: Neal H. Walfield
Subject: Re: Moving to git
Date: Sun, 11 Jan 2009 15:58:53 +0100
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (Gojō) APEL/10.7 Emacs/22.2 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Sun, 11 Jan 2009 12:50:58 +0100,
Thomas Schwinge wrote:
> > >     Rationale: split as far as it's still making sense.  There is no
> > >     reason to have an interger hashing library, a pthread
> > >     implementation, an ext2 file system interpreter, libc amendments,
> > >     Hurd interfaces definition files, a library for providing an
> > >     uniform interface to Mach ports, etc. in the same repository.
> > 
> > Is there a reason to keep them seperate?...
> Yes.  The simple rule of manageable complexity.  Or why are there
> separate repositories for GCC, Emacs, the Linux kernel, X.org, and the
> Intel math lib for IA64?  Is it, at least in theory, more easy to find a
> maintainer for libtrivfs or for the whole set of Hurd libraries and
> stuff?

The ihash library in the main Hurd repo and the ihash library in
Viengoos have significantly diverged.

Whereas e.g. libnetfs is only going to run on something resembling the
Hurd, libpthread really tries to be OS independent.

> Why not?  I see this as one main advantage: I'd be much more comfortable
> with releasing version 0.4 of libnetfs instead of releasing version 0.4
> of the GNU Hurd.  Or finding a maintainer for libnetfs.

Not doing lock-step releases means increasing the configuration space.
I'm not sure this is really helpful.

I'm not yet convinced that splitting the "Hurd" libraries into their
own repositories is the right approach.  It seems to me that these
libraries are tightly coupled and essential to core services thereby
requiring high degrees of coordination anyways.  In which case, why
not keep them all together?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]