(changing the subject) Hi Dave, On Wed, Feb 21 2018 at 06:18:40 PM, Dave Kemper <[email protected]> wrote: > On 2/21/18, Ingo Schwarze <[email protected]> wrote: >> Sure, maintaining macro sets is an easier task than maintaining the >> complicated automake / autoconf / C++ beast as a whole. But i don't >> see how splitting out *easier* parts could possibly help with >> maintaining the harder parts, and even less so with keeping the >> thing as a whole in good coordination. > > Indeed, splitting out easier jobs is a time-honored way to help those > who have difficult jobs. Your brain surgeon is probably not also > answering phones at the hospital's switchboard and managing its > cleaning crew. > > To my view, this *is* a way of supporting Bertrand -- he has > graciously volunteered to be groff's brain surgeon, and perhaps we can > make his job easier by offloading work he's already said he doesn't > feel as comfortable doing.
I'm not comfortable in making non-trivial changes in existing macro packages. However as I leave this work to other persons in the list this does not give my any extra work. For any build issues related to macro package build or installation it's autoconf/automake so it's part of my job. > Sometimes it's better to take the "easy" stuff off the plate of those > who have to deal with the difficult parts, so they can better focus > their attention. Splitting groff into 2 packages would not make my task easier, it would probably make it more complex. When I build groff I check the examples from 'mom' and examples from other macro packages as a sanity check: if, says, the 'mom' examples are broken I can start to look for some problems on my system (fonts, ghostscript version etc...) or for some regressions in the git history. If the macro set were in a separate package it would be an extra source of dependencies and problems. My thoughts on this topic: I don't know how easy it is to use macro package from groff on another *roff implementation. As Ingo said the groff full installation can live on a system with another *roff installation, this works (the build system detects if an existing 'troff' is already installed and add a 'g' prefix to 'troff'). If for some reason the user does not want to install the full 'groff' installation then we could define new make targets, for example 'make macro' and 'make install-macro' to build and install only the macro packages. Would this help? The other thing is that you probably want to have official release of macro packages independantly from releases of the core system. If there is real need for that then we could make some stable branches and intermediate releases, following this flow: - Full version is released, e.g. 1.22.4. - A little bit later a macro package maintainer wants to make a release that has no dependencies on the core system, but there were some non-trivial changes since 1.22.4 and we are not ready to make a full 1.22.5 release. In order to avoid regressions we make a stable branch from tag v1.22.4 and the macro package maintainer commits on it, and creates a 1.22.4-1 release. This is only a matter of a few git commands and is easy to do (compared to having to manage 2 distinct packages). The macro package maintainer could also request the proper rights from GNU to push releases, this does not even require an official maintainer status, I could declare him as a person of trust allowed to make release (there would be some administrative stuff to do though). Regards, Bertrand Garrigues
