[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)
--------------------------------------------------------------------