Greetings.
Traffic and activity on the list got pretty hot over the summer.
Good discussions about underlining, Betrand's automake migration
nearly completed, and Bernd's Herculean labours tackling manpage
updates, licensing, copyrights, and a whole whack of other annoying
but essential details. Plus we've garnered Ingo's valuable BSD
input, and embraced discussion about Heirloom Troff's revitalized
development on the list.
Oddly, I have less free time for projects during the summer than
during the working months, so I haven't done much more than follow
what's been happening. It's September now, and I have time again.
The thread on underlining raised a couple of issues. One is whether
a long-established request (.ul) should be updated. The rationale
is that it's unlikely anyone in 2014+ needs (or, if young enough,
even understands) the current behaviour. However, it's evident from
list comments that we're mostly in agreement: .ul should be left as
is. This reflects an overall feeling about backward compatibility,
which is that it should be fully preserved.
Out of that discussion came Doug's excellent suggestion for a new
primitive, '.decor' or similarly named, that's extensible so various
kinds of decoration can be applied to text, not just underlining
(which, IMO, groff seriously needs).
The addition of useful new requests is part of our mission
statement, and Doug's '.decor' fits the bill. Problem is, the
thread died, and nothing came of it. I suspect that's in part
because we're all leery of mucking about in the sources. It may
also point to a dearth of skilled C++ coders on the list, which, if
true, is something we're going to have to address.
On a similar note, Ulrich Lautner stepped forward to take on
implementing a modified version of Knuth-Plass. He produced a
prototype showing that the application of dynamic programming to
paragraph formatting can be done with a relatively small piece of
code and at high speed. I was excited, but interest from others
hovered around zero. I'm not sure why: from previous discussions,
revamping groff's paragraph formatting is a priority.
If Ulrich is to pursue this (provided he's still interested, and I,
for one, sincerely hope he is), he needs assistance from the list.
Off-list he wrote:
"I am not yet sure if I should try to integrate the code into groff.
The groff code is not that readable, missing comments and common
coding conventions, such as
- using capitalization for class names
- special naming conventions for class members
- access to class members by setters / getters
- avoidance of global variables
So groff could benefit from some refactoring."
He's probably right about refactoring, but the more important issue
is: who, on the list, feels qualified to point him in the right
direction within the code for work on formatting? Myself, I'm not
the best person since my involvement with groff has been almost
exclusively within user-space.
Vaibhaw Pandey stepped forward as a candidate for the role of
maintainer, but he's discovering the job is bigger than he imagined.
One of the issues he raised with me off-list is an apparent lack
of organization. It's true. We have, for a really long time,
essentially been self-organizing. It's worked well and reflects an
ethos to which most of us, I think, subscribe. However, just now,
it's somewhat counterproductive.
Something that would help a lot is for everyone actively involved in
development to post the components/projects they're working on and
where their various expertises and interests lie. This would allow
compiling a list of who's interested in what, who's doing what, and
whose knowledge can be called upon. (Wouldn't hurt to know who
currently has write access to the repo, either). The list could be
posted on the groff webpage and serve to let the world know what's
going on. I'll get the ball rolling by starting a thread.
Vaibhaw suggested that a list of major work that is ongoing in groff
would be helpful, too, with some sort of ETA. I'm not sure such a
list is even possible (esp. the ETAs), but it's a reasonable thing
for any maintainer to want, so we should at consider it. At the
very least, it might help us achieve a bit more focus.
With respect to Vaibhaw's candidacy as maintainer, I propose leaving
the "looking for a new maintainer" notice on the webpage until the
matter is definitively settled. (If everyone's agreeable, I'll take
ownership of the webpage.)
Lastly, except in the case of developers who own particular
projects, let's try to comply with what Werner requested some time
ago: that diffs/patches be posted to the list before pushing them
to the repo. There've been rather more git undos than I think is
healthy, and the reasons for them have been spotted quickly. It
makes all kinds of sense to have other eyes inspect changes before
they go into the repo.
Cheers.
--
Peter Schaffter
http://www.schaffter.ca
