new layout for the book (Gerard?)

Bill Maltby, LFS Organizational bill at nospam.dot
Wed Jan 14 14:14:37 PST 2004


On Wed, 14 Jan 2004, Matthew Burgess wrote:

> On Wed, 14 Jan 2004 08:06:50 -0500 (EST)
> "Bill Maltby, LFS Organizational" <bill at nospam.dot> wrote:
>
> > But I *do* think the
> > comments about the physical storage, at this late date, should not be
> > a major concern and I feel as Matthew stated, effectively, "Where the
> > hell were you from day one?".
>
> That was exactly my feeling last night, I just didn't have the bottle to
> actually say it.
>
> Just to clarify, there are really two elements to the restructuring.
> Firstly (and my main concern) is that the XML *sources* are structured
> in a manner most suitable for our *development* team.

I can't say which is best from an editor's POV. But I can say that in
systems design, development and implementation, modularity is generally
considered a very good thing, for many reasons. And those reasons,
generally speaking, override convenience factors (ease of editing one
huge file vs. a bunch of little ones, less structure to remember and
navigate, etc.).

Whether this holds for the editing team overall, is for you folks who
have to live with it to determine.

Personally (not being an editor, but having a long and diverse systems
design, development and implementation background) I like what I've seen
in the newxml directory.

*But* I am used to working with such structures and that makes it easier
for me to like it than one who is not comfortable with that.

> The second
> (although obviously by no means less important) is the structure of
> the book once rendered (in whatever format) from those sources.

And that stuff that Alex is focused on (disregarding *physical
structure) is what I think should be applied to wherever the team deems
appropriate (I presume HEAD and newxml both?).

> This is
> entirely separate and can be changed at a whim by changing the
> stylesheets.  At this point in time I (personally) don't care what the
> rendered content looks like - I'll leave that to those who are better at
> judging that type of thing.  What I want is a neatly structured CVS
> source repository that is:
>
> a) Easily understood (it's immediately obvious where to find things when
> you want to do what should be a 2 second change)
> b) Sensibly separated. i.e. There's no repetition of common content,
> whether that be entire sections of text (appendixa style stuff) or of
> individual pieces of text (like package version numbers).
>
> Many thanks go to anyone who offers critical evaluation of the current
> state of the LFS/newxml module.  I realise that everyone's pushed for
> time, but so am I.  I just got the feeling last night that Alex was
> effectively saying I'd just wasted all the snatched hours of time I did
> have available (even though the wife didn't think I did!) all for
> nothing, and largely through no fault of my own.  I'm not the only
> editor on LFS, everyone has a stake in this (sub)project.  If you don't
> like what you read on lfs-book then for god's sake shout up
> *immediately*, or even better give me your thoughts and ideas
> before-hand.  There's a TODO and README in there, peruse it, mull it
> over and if anything strikes you as plain wrong then let me know.  I
> can't please anyone if I don't know what you want.

I had read the TODO and README as soon as they were posted. I can not go
further until I feel comfy in making the changes needed for the
rendering side. Timing (in relation to status of my workstation build)
was unfortunate.

>
> Best regards,
>
> Matt.
>

-- 
Bill Maltby,
LFS Organizational
billATlinuxfromscratchDOTorg
Use fixed above line to mail me direct



More information about the lfs-dev mailing list