This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Preferred Format of GNU C Library Manual Edits


Hi glibc,

I'm roughly halfway through the manual (working on grammatical edits),
and now I need to know how I should start formatting/preparing my
patches.  This is generally directed at whoever will be reviewing the
patches, so as to make your part easier.

I'm at a point where the last few chapters have gone rather smoothly in
terms of what I choose to edit, ignore, or makes notes of for future
reference; i.e., I'm largely past the point of constantly asking myself,
"[How] Should I edit this?"  Now that I have a reasonably consistent
style and scope, and have learned enough git to be both useful and
dangerous, it's time to return to those earlier chapters and
rework/review them.  On top of cleaning early messes, this also provides
the opportunity to set up my workflow for the remainder of the manual.

To give you an idea of how I'm structuring things, let me describe the
perspective here in why-did-I-start-editing-the-manual land.  Foremost,
I don't intend to read this thing cover-to-cover twice (not that
continued work won't eventually cover that much ground though).  To make
the most of this first pass, I see 2 primary groups of edits that if I
were to ignore for now, but wanted to come back to later, would
essentially result in reading the entire manual word-for-word over
again.  One set is purely grammar related, and the other is variable
formatting, which, assuming a variable's name should be formatted as
code and its value in italics, is atrocious throughout.

Since the two groups are independent issues (unless you actually read
variables like their formatting matters, in which case it does feel like
a minor grammar issue), I've been editing them in parallel.  One branch
for grammar, another for variable formatting.  Another reason for
keeping them separate is I expect they'll be subject to entirely
different opinions, and I would hate simple grammar fixes in a mixed
patch set to be blocked because I couldn't tell the difference between
the variable @code{size} and a string @var{size} bytes long.

Another class of edits worth mentioning is reference formatting.  These
wouldn't be so bad to grep for and examine, but improperly formatted
references are fundamentally a grammar issue because of how they render
in the different output formats.  So far, I've included them in the
grammar edits, but I could do something similar to variable formatting
and cut them out into their own branch, if anybody thinks that would be
useful or more appropriate.

Getting to the actual patch submission part of this, the way I plan on
doing it is something like:

[Patch M/N] Grammatical edits to the GNU C Library Reference Manual.

where each M is a chapter.  Variable formatting and other manual-wide
topics would follow similarly.


Let me know if anything I've described should be changed in any way.

Thank you,
Rical Jasan

Attachment: signature.asc
Description: OpenPGP digital signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]