Re: Further Git repositories?

[olafBuddenhagen]

Hi,

On Tue, Aug 11, 2009 at 12:12:51PM +0200, Thomas Schwinge wrote:
> On Sun, Aug 09, 2009 at 06:20:41PM +0200, olafBuddenhagen@gmx.net
> wrote:
> > On Sun, Aug 02, 2009 at 02:05:30PM +0200, Thomas Schwinge wrote:

> > > Now, for publishing last years' GSoC projects etc., we'd need
> > > another bunch of 'em: for the projects that create new ``modules''
> > > (procfs, LISP stuff, libchannel, eth-filter, eth-multiplexer,
> > > proc_proxy, nsmux, ...) -- I'd like to have theses in separate
> > > repositories instead of muddling all of them into the Hurd proper
> > > repository.
> > 
> > Why? Who exactly would would benefit from that?
> 
> We can't keep the whole world in one repository.  (Actually, we could,
> but we don't want to.)

No, we can't keep the *whole* world in one repository. But we can keep
our little part of the world in one repository perfectly well :-)

You haven't answered my question at all: who would benefit from such a
split, and why? Such a thing should never be an end to itself -- it only
makes sense if it solves actual problems we are experiencing...

Don't get me wrong: I totally agree that modularization is useful in
many situations, and thus often a noble goal. But are you sure the Hurd
tree is one of these cases? It seems to me that the situation here is
somewhat different than in many other cases, and a split wouldn't really
be to our advantage in this case...

For one, it is different in that we don't have to deal with a lot of
activity, so developers of different components are not likely to step
on each others toes anyways.

It's also different in that the components in question are not really
very independent: a change in the interface of each library, but also of
each server, always requires the other components to be updated.

And the Hurd small and simple enough, and there are so little external
things depending on us, that people never have the requirement of
keeping some components unchanged while updating others.

Keep in mind that modularization doesn't come for free. (Neither in
terms of the initial conversion, nor ongoing maintenance.) On the
contrary -- it tends to be very costly. API and ABI versioning; keeping
components in sync that live in other repositories; and coordinating
releases: these are all very painful things. (Ask any Xorg developer.)

In many situations, there are other advantages however, which make up
for this cost. But do any of these really apply to the Hurd in the
current state?...

BTW -- as once you mentioned Xorg as an example in favor of
modularization -- you might be interested to hear, that the developers
seem to be getting serious about plans for remerging the relevant
drivers into the server: they want to avoid the pain of having to keep
things in sync between components that aren't really independent at
all... And I think our situation is actually very similar to the X
server and drivers in terms of component independence.

> > > But instead of creating a full-fledged (separate) Git repository
> > > for each of the projects, I propose to have a ``dump'' repository
> > > in which there are several independent branches (`lisp',
> > > `channel', `eth-*', ...) containing the respective files.
> > 
> > Sounds like a mess. What is the advantage over branches in the main
> > repository?
> 
> Somewhere the line has to be drawn between what is considered part of
> the official Hurd distribution, and stuff that is currently in the
> incubator.

Don't you think that branches are perfectly suitable for handling
experimental stuff? I don't see any technical disadvantage; and as for
formal reasons, I firmly believe that we should encourage new
development by treating as much things as realistically possible as part
of the main distribution.

> In my book, the collect-'em-all hurd/hurd.git repository is not the
> way to go for the future -- that's why I don't intend to add new
> modules to it, but instead use separate repositories per module.

What is considered the way to go for the future, and what makes sense
right now, are two different things... Even if you have plans ultimately
to split the repository, that's not a good reason to discriminate new
components right now.

Not only does it put the new components at a disadvantage in practice
right now; but also it's IMHO fundamentally wrong to create facts for
something there is no consensus about so far...

> (We discussed this already.)

Indeed we did (both the question whether a split is desirable at all;
and the point that independent of the outcome, indefinite plans should
not be an excuse to deny new modules an equal place right now) -- but
the previous discussion came to no conclusion, so it was inevitable that
the issue pops up again...

-antrik-