Splitting the Hurd tree

[olafBuddenhagen]

Hi,

On Sun, Jan 11, 2009 at 12:50:58PM +0100, Thomas Schwinge wrote:
> On Fri, Jan 09, 2009 at 09:38:20AM +0100, olafBuddenhagen@gmx.net
> wrote:
> > On Sun, Jan 04, 2009 at 12:05:07AM +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.

Note that splitting things up *increases* overall complexity.

In exchange, complexity is somewhat isolated, so in some cases the total
amount of complexity you have to deal with at a particular moment is
lower. This can make it worthwhile.

I don't see such benefits from splitting the Hurd repository in the
current situation, though.

> Or why are there separate repositories for GCC, Emacs, the Linux
> kernel, X.org, and the Intel math lib for IA64?

This is not comparable at all: These projects have vastly different
history, goals, licenses, philosophy; completely different and almost
non-overlapping sets of developers; different policies, release
schedules; users and distributors are upgrading them independantly; most
of them are not unique, but rather among various competing projects
offering more or less similar functionality, which can be used in all
kinds of combinations. And each one of them (except for the last
perhaps) alone sees several orders of magnitude more activity than we
do.

None of this is true for the Hurd, as of now.

> Is it, at least in theory, more easy to find a maintainer for
> libtrivfs or for the whole set of Hurd libraries and stuff?

Wrong question. Right one would be: Is it easier to find maintainers for
*all* the individual modules?...

Also note that it's perfectly possible to have different maintainers for
the components, without having them in different repositories. Xorg had
that before the split AFAIK.

> > >     libihash and libpthread are shared between Hurd and Viengoos.
> > 
> > I agree that these should be split out
> 
> Then, why just these two?

Becasue there is actually a *reason* for splitting out these: They are
used in two different places. Independant releases are inevitable, if we
want to keep (or rather restore) a common code base.

That's presently not the case for any other of the components.

> > We would need to start some proper versioning, which is quite a
> > pain.
> 
> Proper versioning is a standard technique these days.  I don't see any
> problems.  Where do you see problems?

It is a lot of effort to release individual modules, to keep track of
dependencies, to make sure dependencies do not conflict, to keep things
in sync etc. I see that daily in Xorg. Several developers are actually
arguing for partially undoing the modularisation...

The difference is that for Xorg, the additional effort is justified:
There are enough developers working on all kinds of things in parallel,
that trying to release everything at once means a lot of coordination
efforts and inevitable stalls. The modularisation helps a lot there.

Our situation is very different, however.

If the Hurd really takes off one day, and can boast dozens or hundreds
of active develorpes, things might change. We will certainly reconsider
it then. But that's not what we have now. Now, it would be just
additional effort without any real benefit.

> > And what would the benefit be? It's not like we ever release these
> > modules seperately... (At least not in the forseeable future.)
> 
> 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.

Aside from the fact that 0.3 is the next to come: Why are you
uncomfortable with releasing a new version of Hurd? I don't see any
problem with that.

-antrik-