Re: procfs, separate repo?

[Richard Braun]

On Wed, Jul 04, 2012 at 08:29:13AM +0200, Thomas Schwinge wrote:
> On Tue, 3 Jul 2012 21:19:12 +0200, Richard Braun <rbraun@sceen.net> wrote:
> > Unless it's very easy to use submodules, we should use one repository.
> > Other projects with much more content and history have showed it's
> > perfectly sane to keep that much in one place, and it simplifies keeping
> > the tightly coupled modules of the Hurd in sync.
> 
> On the other Hand, one of the Hurd's unique characteristics is that it is
> *not* a big monolothic blob like other systems, but instead does have
> clearly defined interfaces allowing (and encouraging!) for separation of
> components.  I think that keeping our operating system modules separate
> helps to highlight this fact, which is why I already years ago favored
> separation over putting it all into one repository.  Of course,
> decoupling stuff too much comes with additional maintenance burden, so we
> have to set a limit somewhere.  But, packaging procfs as its own Debian
> package (like other translators are too) from its own source tree
> shouldn't need much maintenance effort, I think?

It's also one of the things that make it tedious to change things, and
can keep developers away (me being one of them). Also, I consider procfs
part of the core servers as it is required for some often used coreutils
and psmisc tools to work. It's fine to keep the less often used (and
maintained) extra Hurd programs (such as xmlfs) external, and we could
even remove those that got to this state (such as ufs and bsdfsck) from
the main repository, but anything that is used and actively maintained
(or very simple to keep in sync) should be close to the core code.

-- 
Richard Braun