Hi, On Tue, Aug 11, 2009 at 12:12:51PM +0200, Thomas Schwinge wrote: > On Sun, Aug 09, 2009 at 06:20:41PM +0200, olafbuddenha...@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-
