groff
[Top][All Lists]
Advanced

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

Re: Proposed: 3 disruptive changes for groff 1.23.0


From: Dave Kemper
Subject: Re: Proposed: 3 disruptive changes for groff 1.23.0
Date: Sun, 27 Jun 2021 04:46:18 -0500

On 6/26/21, Bjarni Ingi Gislason <bjarniig@rhi.hi.is> wrote:
> On Fri, Jun 18, 2021 at 01:48:15AM +1000, G. Branden Robinson wrote:
>> 1. "Skip the stripper".  Mooted several times on this list in the past,
>>    this proposal to stop shipping some macro packages (hdtbl, mdoc, and
>>    "me") in a condensed, hard-to-read form akin to JavaScript
>>    minification already enjoys a consensus, but was shelved on perceived
>>    scheduling grounds.
>>    <https://savannah.gnu.org/bugs/?55091>
>
> a) I do not see a consensus;

The bug report at the URL above links to past mailing-list threads
from 2017 to 2019 showing pretty consistent agreement about this.  The
2019 thread even contains data on the performance difference between
stripped and unstripped versions when processing a large mdoc
document, showing this difference to be negligible.

> there is no voting,
> no resolution,

Our process has never been that formal.

> no mentioning of side effects,

You are free to mention any side effects that concern you.

> thus no informed consensus,
> just people speculating,
> showing (me at least) a startling lack of
> 1) knowledge
> 2) intelligence.

You can argue your case as strongly as you like, but insulting other
list members is not likely to win over many people.

>   Not using such a file makes the software less effective;
> thus such a move is simply a sabotage.

Please give some concrete examples of ways in which it is less effective.

>   Is there also a consensus, that the maintainer, that introduced this
> mechanism of removing meaningless (time, energy, processing cycles
> wasting) bytes, made a mistake, an error?

No, I think it's pretty widely understood that performance was more of
a concern in the past than it is on 21st-century hardware.



reply via email to

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