[arch-general] Proposal: add "--disable-modern-top" to procps-ng configure flags

[Eli Schwartz]

On 12/09/2017 07:10 PM, Jonathon Fernyhough wrote:
> If there's a single configure flag (as already used by two large distros
> and derivatives) that makes `top` suck "less" surely that's also an
> option - especially if the default is _known_ to suck and the upstream
> project did it on purpose.
> 
> Yes - they changed the default to try and force people to read the
> documentation. Most people just switched to `htop` instead [citation
> needed].

I certainly switched to htop as a response, but I made no claim about
anyone else...

> I submitted, what I thought, was a reasonably structured and detailed
> proposal to change one flag in a PKGBUILD file which would have few (if
> any) side effects.

Adding extraneous flags as a political decision to deviate from upstream
defaults is itself a side effect. We will not do this without
significantly more justification than "I dislike how it looks and don't
want to write my own config file". In the truest spirit of Arch Linux,
we would like "defaults suck and no one can read this garbage" to be
fixed upstream, while Arch users will likely read the manpage and set
their own configuration (though I personally encourage switching to
htop, which not only fixed my gripe with top, but turned out to be the
process viewer I hadn't realized I was missing).

> The whole point of a proposal is to drive a discussion; there is no
> assumption it is absolutely correct. I don't see that as "griping". If
> I'd just said "top sucks, you should fix it", then fine - but I didn't
> do that.

You said "top sucks, let me list the reasons why I don't like it". This
is no better!

Turning a gripe into a bulleted list of gripes does not constitute
migrating from a gripe to a "proposal"; being a "proposal" says nothing
whatsoever about its status as a technical merit vs. political change.

So we'd have to look at the *content* of your proposal... and there we
hit into the issue that you just responded to by claiming that "OMG it's
a proposal not a gripe" without actually saying anything.

Namely, you agree it is subjective but want to argue about whether
everyone agrees with your subjective opinion. But... Arch does not and
never has and never will care about peoples' subjective opinions merely
for the sake of subjective opinions. We expect people to read manpages
and configure software for themselves. We don't add changes to upstream
except for clearly defined reasons, and configuring things on behalf of
the user is not one of these reasons.

So excuse me, but in what possible world did you either file that
bugreport or start this discussion thread with the belief that you had
any chance whatsoever of getting this changed? This whole issue
approaches the level of a deliberate spam comment... and given that you
are *that* jonathon, I am not going to buy ignorance as an excuse.

>> Mind you, we didn't realize you were a Manjaro user. 
> 
> I assumed my email address might be a giveaway.

Guilty! I only looked at your email address after I sent the email.

>> So you have another option too -- ask Manjaro to override our package with their own, since
>> naturally Manjaro as a "value-added Arch derivative for beginners" would
>> want to validate their existence by, well, adding value for beginners.
> 
> I've already released an updated package (as per link [5] in my OP). As
> I said somewhere else (maybe on the Arch forum?), if raising changes
> "upstream" can benefit the whole ecosystem it's worth doing.
> 
> I'd probably dispute the "for beginners" bit though... ;) Plus, we
> really don't need to validate our existence, thank you.

Awesome! So happy that a mutually satisfactory outcome was obtained!

Now why does this mailing list thread exist...

-- 
Eli Schwartz