groff
[Top][All Lists]
Advanced

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

Re: [Groff] Who is doing what


From: Ingo Schwarze
Subject: Re: [Groff] Who is doing what
Date: Wed, 10 Sep 2014 01:58:56 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Feel free to use inside the groff project in any way you like,
including republishing and including in official lists,
but please don't change the content without speaking to me.

--------------------------------------------------------------------
Ingo Schwarze:

Projects/components
 - maintainer of the OpenBSD groff port and author of the gpresent port
 - maintainer of the mandoc = mdocml toolbox (not a part of groff)
 - general OpenBSD userland development

Specific short/medium term projects:
(mostly a sneak preview of my "possible future directions" slide
 from my upcoming EuroBSDCon tutorial on software documentation,
 to be delivered later this month in Sofia, Bulgaria)
 - replace the traditional BSD man(1) implementation with the
   recently completed one from the mandoc toolbox (system
   integration task)
 - switch the default mandoc(1) output mode from -Tascii to -Tlocale
   (system integration task)
 - integrate the existing mandoc preconv(1) implementation into the
   mandoc(1) program for better UTF-8 handling
 - improve pod2mdoc(1) to better support perlpod(1) to mdoc(7)
   transitions, in particular for the LibreSSL manuals
 - support automatic semantic enrichment of Perl manuals with
   pod2mdoc(1) - not sure yet this is practicable, just an idea
 - support semi-manual transitions from man(7) to mdoc(7)
   by chaining doclifter(1) with docbook2mdoc(1)
 - unify mandoc(3) parsers, allowing more low-level roff(7)
   improvements in mandoc(1), makewhatis(8), and apropos(1)

Competences
 - Perl
 - C
 - mdoc
 - sh
 - system integration

Prepared to
 - always perform release testing on OpenBSD
 - do master testing on OpenBSD now and then
 - maybe maintain gpresent, not sure what the current upstream status is
 - perform groff_mdoc(7) maintenance when needed
 - probably, *very* sparingly add features to the mdoc(7) language,
   provided that consensus can be reached with the groff crowd in
   each individual case, that i manage to implement the feature
   cleanly in both groff_mdoc(7) and mandoc(1), and that backward
   compatibility is not too badly broken - just as an example, we
   may need to allow multiple "architecture" arguments to the .Dt
   macro to support manuals pertinent to multiple, but not all
   architectures, for example fdisk(8)

--------------------------------------------------------------------



reply via email to

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