Subject: bug#33787: Policy Change: Use of /etc/gnu.conf files to configure default system behavior

From: Assaf Gordon <[email-masked]>
Date: Mon, 31 Dec 2018 07:16:01 -0700

Hello,

On 2018-12-31 6:24 a.m., L A Walsh wrote:
> On 12/31/2018 4:23 AM, Assaf Gordon wrote:
>> these are all tangents.
>> The topic of this thread is adding support for a global configuration
>> file.   That request is not likely to be implemented.
> ----
>      One of the main points here was that some of those other features 
> were discarded because there was no easy way of providing
> a default configuration for how users wanted these things.

I'm not familiar with any feature request that was rejected because
there was "no easy way of providing default configuration".

Feature requests/suggestions might be rejected because coreutils
maintainers were not convinced they were warranted or useful
or did not pass muster in the trade-off between bloat and functionality.

Again - this is not about a generally rejected feature, but about a
feature that was deemed useful but was rejected because there was no
easy way to configure it (or, control it from the command line?).

If there are specific cases of requests that were denied because there
was no easy way to configure the feature - please provide a link
to such discussion - that will help more the discussion forward.

>> To continue discussing other topics or feature requests (e.g.
>>   tab-expansion) - please start a new dedicated thread.
> ----
>      Dedicated to what?

Dedicated to one topic.

"Adding global configuration file to all coreutils programs" is one
such topic. Implementing 'rm --depth-first' is a completely different
topic and should be discussed in a separate thread. Adding tab-expansion
to program X is yet another distinct topic.

> Each problem that need a configuration file?  Or a configuration 
> facility to provide a ready backdrop to allow for tool extensibility?
> It seems they are interrelated.

Interrelated does not mean they are the same topic.

To help clarify, in the context of "coreutils" think of a "topic" as
a task or feature that a programmer develops.

Adding "rm --depth-first" feature is a task that a programmer can
develop regardless of whether program X supports tab-expansion.

Adding support for global configuration file is a task that can
be completed regardless of whether rm supports "--depth-first" or not.

etc. etc.

As such, it helps us (coreutils maintainers) and others (anyone else
who is subscribed to the mailing list) to keep each thread to one topic.

That way, a discussion thread has a start, middle, and (hopefully) end.

If a thread goes on and on and covers multiple topics, it makes it
hard to keep track of what is going on and what is discussed.

This is especially true for mailing lists which use the bug tracker
(like [email-masked]).
Every new topic email creates a new bug report page.
In this thread it is here: https://bugs.gnu.org/33787 .

If the thread is long and covers many topics, it makes it very hard
to manage bugs (e.g. classify them and address them).

> I seem to remember this statement by you:
> 
> "Discussion can continue by replying to this thread."

Always true.

But it helps if the discussion is focused on one topic (the original 
topic from the first message in the thread).

regards,
  - assaf