bug-hurd
[Top][All Lists]
Advanced

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

Re: unionfs Documentation


From: olafBuddenhagen
Subject: Re: unionfs Documentation
Date: Sun, 16 Aug 2009 20:06:28 +0200
User-agent: Mutt/1.5.19 (2009-01-05)

Hi,

On Tue, Aug 04, 2009 at 01:00:10AM +0200, Thomas Schwinge wrote:
> On Fri, Jul 17, 2009 at 05:08:28AM +0200, olafBuddenhagen@gmx.net wrote:
> > On Sat, Jun 13, 2009 at 09:23:23AM +0300, Sergiu Ivanov wrote:

> > > I'm sending in my attempt to compile a unionfs documentation. It
> > > is formatted as a stand-alone Texinfo file for now, so that I am
> > > able to build and view .info files from it.
[...]
> > put it in the normal Hurd manual, where the "shadowfs" placeholder
> > used to be.
> 
> I disagree: let's please put it into the unionfs repository and render
> into a separate info file.  Sergiu, then please remove the shadowfs
> reference(s) from the GNU Hurd Reference Manual.  unionfs is not an
> integral core part of the GNU Hurd kernel infrastructure, even is held
> in a separate repository, and thus doesn't really belong into the
> GHRM.

It certainly was *meant* to be, as evidenced both by the mention in the
design document, and by the placeholder in the manual.

It was a mistake that unionfs was not added to the main repository in
the first place. This should be fixed, rather than proliferated.

> (Of course I'm not saying that unionfs was an unimportant part for the
> envisoned GNU system.)

The vision hasn't changed, to the best of my knowledge.

> > > @node Basic Internals
> > > @chapter Basic Internals
> > > @cindex internals, node, light node, conflict
> > > 
> > > In this chapter a short description of how @command{unionfs} works
> > > will be done. This description is intended for people who have at
> > > least a vague idea about GNU/Hurd translator programming.
> > > 
> > > Note that what follows is an overview of the basic functionality.
> > 
> > I don't think the introduction paragraphs are necessary.
> 
> Without having at all looked at them so far, why remove them?

A meaningful title, like "implementation", is sufficient. You don't need
two paragraphs to explain what this is. People reading the manual aren't
morons. Bloating the text with useless fluff only makes it harder to
read.

-antrik-




reply via email to

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