On 09/12/17 16:21, Doug Newgard via arch-general wrote:

On Sat, 9 Dec 2017 15:39:46 +0000 Jonathon Fernyhough wrote:

...

The "modern" default interface:

* requires user configuration to make usable;

Completely subjective

...

* uses low-contrast text;

So? This is personal preference

...

* is not consistent with other distros;

Nobody cares

...

* has caused confusion to Arch users [2].

Nobody cares

What you have left out is that your proposal has already been rejected (https://bugs.archlinux.org/task/56639). Complaining in every venue you can find does nothing other than make people ignore you in the future.

I thought that a more fully-formed proposal with more detailed rationale sent to the mailing list where devs might read it might have made the case better, but if that's "complaining" then I guess I really don't understand how you do things. Thanks for spending the time to consider the proposal and for your valuable input, nevertheless. If anyone is willing to help me contribute in a way that isn't viewed as "complaining" please point me in the right direction. J

On Sat, 9 Dec 2017 10:55:51 -0600 Doug Newgard via arch-general wrote:

On Sat, 9 Dec 2017 16:31:21 +0000 Jonathon Fernyhough wrote:

...

If anyone is willing to help me contribute in a way that isn't viewed as "complaining" please point me in the right direction.

And now you're asking how to complain without it being viewed as complaining. The decision was made, move on unless you have a compelling argument you haven't brought yet. Contributing is fine, harping on something that's already decided and done (2 years ago!) is not contributing.

Correction, that should be 3 years ago.

On Sat, 9 Dec 2017 17:19:22 +0000, Jonathon Fernyhough wrote:

Just because something was "done" two years ago doesn't mean there's not a better way of doing it.

I guess you read [1] and [2]. As a side note, don't worry about the out-of-date flag from yesterday. IIRC procps-ng-classic from AUR never caused an issue, at least I can't comment the 3 comments at https://aur.archlinux.org/packages/procps-ng-classic/ . [1] https://lists.archlinux.org/pipermail/arch-general/2017-December/044497.html On Sat, 9 Dec 2017 18:05:14 +0100, Tinu Weber wrote:

In this particular case, ask upstream (as also pointed out on the bug tracker). Arch Linux does not patch software or deviate from its default behaviour unless absolutely necessary (usually in case of bugs that make an application unusable).

[snip]

An personal advice from my side, as I have also been burnt by that: Don't try to discuss Arch Linux packaging decisions. There is nothing you can really do. The least frustrating approach is to simply package stuff your own and fix the things that annoy you (and from what I see, you're already doing that).

[2] https://lists.archlinux.org/pipermail/arch-general/2017-December/044496.html On Sat, 9 Dec 2017 18:00:01 +0100, Ralf Mardorf wrote:

I'm using procps-ng-classic from AUR since 2014. [snip]

On Sat, 9 Dec 2017 17:47:19 +0000, Jonathon Fernyhough wrote:

On 09/12/17 17:31, Ralf Mardorf wrote:

...

On Sat, 9 Dec 2017 17:19:22 +0000, Jonathon Fernyhough wrote:

...

Just because something was "done" two years ago doesn't mean there's not a better way of doing it.

I guess you read [1] and [2].

Yes.

Two people reply to the list who use or package their own alternative version because of the aggro of suggesting changes to packages when, e.g., upstream might not care or upstream's decisions might not be a one-size-fits-all.

While this is devolving into https://wiki.archlinux.org/index.php/Code_of_conduct#Ineffective_discussion_..., if people are actually afraid to post I'd suggest that might be something to look at.

J

(Yes, I'm done now ;)

As already pointed out off-list. Take things with a good sense of black humour! C'mon! It's nearly impossible to find a more useless default, than the PID 1 systemd tree and without the slightest doubt everybody is aware of this.

On 09/12/17 23:36, Eli Schwartz via arch-general wrote:

You proposed changes after three years of an *upstream* default, when Arch is a distro designed around the philosophy of packaging *upstream* code, and when the appropriate response is to either: 1) Convince upstream their default sucks. Because the default does indeed suck, 2) Spread the word to all and sundry, that the default sucks, hopefully eventually the procps-ng maintainers will realize there is nothing "modern" about this. 3) Come to the sneaking realization that, yes, top sucks, but not just because of this -- and ditch top for htop. Because top sucks, and --disable-modern-top will not fix that.

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].

We're generally fine with "I'm not a Dev", where do you think TUs eventually come from? People who contribute with ideas, help, infrastructure suggestions, etc. Griping about a rather obviously subjective *policy* decision is not, however, a "change", it's a political request that assumes everyone agrees with you about how top "should" look (and clearly some people like it, or even upstream wouldn't support it).

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. 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.

Mind you, we didn't realize you were a Manjaro user.

I assumed my email address might be a giveaway.

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. J

On 10/12/17 00:27, Eli Schwartz via arch-general wrote:

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).

I thought that e.g. accessibility and user experience was greater justification than "I dislike it". Granted it's not the raison d'etre of Arch but with such a small commitment/maintenance burden I honestly couldn't see the harm in it. If I could I wouldn't have bothered with any of this.

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.

Providing an implementation with rationale (whether or not you agree with it) is definitely not "griping". If someone submitted a PR which changed code you wouldn't call it political. This is no different.

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.

I don't know what else you want. I remember (in another life) someone saying "unless someone has a substantive reason", which really meant "unless there's something involving money". Anything else wasn't "valid". In this case... I don't honestly know. What could/should have been a quick discussion has moved into what's approaching a philosophical discussion, which certainly wasn't my intention.

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...

"If you have a question regarding Arch development, please ensure that your topic poses a specific question and be open-minded to responses. If possible, provide a solution or partial solution. Submitting code and patches for discussion is always more pragmatic than asking others to do it for you."

and given that you are *that* jonathon, I am not going to buy ignorance as an excuse.

Thank you.

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

I'm glad the discussion was productive, sarcasm aside. J

On Sat, Dec 09, 2017 at 09:27:49PM -0600, Doug Newgard via arch-general wrote:

On Sun, 10 Dec 2017 00:10:15 +0000 Jonathon Fernyhough wrote:

...

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.

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.

To be clear, the real issue people are having with you here isn't your proposal. It's the fact that you submitted it to the bug tracker, the maintainer saw it, thought about it, and rejected it...

In general, discussions about defaults are silly, as long as things are configurable at run-time, so I don't understand why that bugreport was accepted at all... Cheers, -- Leonid Isaev

I'm using procps-ng-classic from AUR since 2014. [rocketmouse@archlinux ~]$ yaourt -Ss $(pacman -Qo /usr/bin/top | awk '{print $5}') aur/procps-ng-classic 3.3.11-1 [installed] (Out of Date) (3) (0.00) Utilities for monitoring your system and its processes (with classic top) [rocketmouse@archlinux ~]$ grep -m1 procps-ng-classic /var/log/pacman.log | awk '{print $1}' [2014-11-19

[2017-12-09 16:31:21 +0000] Jonathon Fernyhough:

Thanks for spending the time to consider the proposal and for your valuable input, nevertheless.

Your sarcasm is really pissing me off because I did take the time to review your bug report before replying with my analysis and two constructive suggestions for you. Let me recall them to you: Just write a `.toprc` to enforce your favorite options; problem solved. And if you really feel strongly about the new interface not matching your definition of "progress" you should bring your suggestions upstream. And what did you do with this "valuable input"? Conveniently ignored it so you could go on ranting and trying to rally people to your "cause". Guess what? That's not how change happens in open source circles, that's just a way to piss people off and make them ignore your future requests. So if you're serious about change start coding already and send pull requests upstream. -- Gaetan

On 09/12/17 20:59, Jonathon Fernyhough wrote:

https://gitlab.com/procps-ng/procps/issues/78

For info, marked as dupe of https://gitlab.com/procps-ng/procps/issues/6, the first reply of which contains:

Anyway, packagers have the option to preserve the old top defaults at build time, which Fedora has done. Archlinux appears to offer an alternate 'classic' top version too.

I presume the "alternate" mentioned is the AUR package already pointed out. So, it comes down to a packaging decision which has already been made. As this isn't going to change I'll let you good folks get back to your Saturday. :) J

Apologies if this is misformatted, and I hope it works; I didn't expect to be responding and am working in the system optimized for readability over composition. I subscribed to this list just last night in hopes of gaining better visibility into the tools that I use. I have, and I think that I should report my findings. This thread has convinced me to, first, unsubscribe from this list immediately, because the information isn't worth exposure to this kind of toxicity, and second, start moving away from Arch, because I can't trust it to ship good code. The immediate response and a good bit of the followup was acutely hostile to both the reporting user and to the ability of this community to build good software. It argues to me that I cannot trust Arch to comprehend a world outside its little bubble, think about its users, acknowledge possible bugs that aren't instantly obvious to the Arch staff, cause issues to be upstreamed, or maintain a climate of discussion that is conducive to discussing problems and fixing them. Evaporative cooling of group beliefs ensures that honesty-brutality culture inevitably spirals into a festering close-minded pit that cannot accept outside contributions or think of the bigger picture. Maintaining the free flow of information is important, but it must be done in the context of the larger community - a tiny walled-off group can communicate as freely as it wants inside itself, but if nothing goes over the wall there might as well be no free flow at all. Even if the original report was not flawless, even if it was a repeat, even if it was sent to the right people, hostile repression was not the correct response. If nothing else, the fact that it's a repeat should be demonstrated and more deeply evaluated. This time it ended up working out, but if this is representative of the Arch community I can't trust it to handle other bugs. How many more severe issues are hiding in Arch, or in upstream packages, because the original reporter was already having a bad day and just gave up? Because people aren't emotionless robots and a horrible thread like this stressed someone out enough to cause an error? Because someone jumped to an incorrect conclusion and shut down discussion prematurely? Answer: Too many for my liking. -- Saul Reynolds-Haertle

Well, that was a good use of "reply"... Apologies.

On 09/12/17 23:51, Morten Linderud via arch-general wrote:> I think we both know very well that the state of security in Manjaro is way

worse then Arch.

Ah, that old chestnut again. :) At the risk of going entirely off-topic, you might also note the difference in how your input on the Manjaro forums was received compared to similar on the Arch forums. J

Subject: Re: [arch-general] Proposal: add "--disable-modern-top" to procps-ng configure flags Quoth Saul Reynolds-Haertle

This is an absolutely horrible response and let me tell you: telling others what to do is not how you should live, think, use computers or (FOSS) software. So first of all, I hope you use computers because they make getting your job done easy enough _to you_. Anything beyond can in fact be viewed as you acting irresponsibly.

Apologies if this is misformatted, and I hope it works; I didn't expect to be responding and am working in the system optimized for readability over composition.

What does your first paragraph even mean? You hope we see your reply in a way that pleases us, which might be on braille readers or piped to espeak to be played on commute. You carry a hint of how others are supposed to receive your content, and you state this first, maybe because you think that's more important than what you're actually saying. Then you say something about how you have to be "working in the system", which I'll just interpret as you running your mail program as root. *shrug*. That system is then optimized for readability over composition. Both terms so overused since the invention of the personal computer that I don't even remember what they mean any more.

I subscribed to this list just last night in hopes of gaining better visibility into the tools that I use. I have, and I think that I

The twist in "gaining better visibility into the tools that I use" is nothing short of brilliant. I hardly understand the sentence, right between "you'd like to gain better visibility", as in you want to be seen and "visibility into the tools", which might mean that you imagine you're swimming in more bright blue waters somewhere closer to where the software you're using comes from. Thing is that this isn't some zelda role-playing game. You're talking to actual people with actual responsibilities and actually share their time with their work, their families and whomever else they decide to spend their lives with.

should report my findings. This thread has convinced me to, first, unsubscribe from this list immediately, because the information isn't worth exposure to this kind of toxicity, and second, start moving away from Arch, because I can't trust it to ship good code.

So one thing that hasn't existed 10 years ago is framing fiction as facts like you are doing it here. You're basically imagining that you have to stay away from discussions where somebody tells you you're wrong, and completely caricature any act of verbal violence against you by completely ignoring whether they might have had a point. Either you're caught in a case of backfire effect or you were told how terribly things were going around here only looking for some confirmation - See also: confirmation bias.

The immediate response and a good bit of the followup was acutely hostile to both the reporting user and to the ability of this community to build good software. It argues to me that I cannot trust

Community? Build? Good? Software? Dude, most of us got the package in question on their hard drive from a pacman -S under some sort of brain-outage or automatically by whatever installation script they had at the time they installed it. That said, yes, some hostility might occur. I'll get to what you should do with it in a minute.

Arch to comprehend a world outside its little bubble, think about its users, acknowledge possible bugs that aren't instantly obvious to the Arch staff, cause issues to be upstreamed, or maintain a climate of discussion that is conducive to discussing problems and fixing them. Evaporative cooling of group beliefs ensures that honesty-brutality culture inevitably spirals into a festering close-minded pit that cannot accept outside contributions or think of the bigger picture. Maintaining the free flow of information is important, but it must be done in the context of the larger community a tiny walled-off group can communicate as freely as it wants inside itself, but if nothing goes over the wall there might as well be no free flow at all.

You know you're slandering. What you're saying is because you did not get your say, nobody gets their say even if they might be right, and the people who create the content (PKGBUILDs for our packages) have all the time they need to grant every unimportant user's wish. Last time I checked, nope, that's not the case. Double-checking, because you seem desperate, nope, still not the case.

Even if the original report was not flawless, even if it was a repeat, even if it was sent to the right people, hostile repression was not the correct response. If nothing else, the fact that it's a repeat should be demonstrated and more deeply evaluated. This time it ended up working out, but if this is representative of the Arch community I can't trust it to handle other bugs. How many more severe issues are hiding in Arch, or in upstream packages, because the original reporter was already having a bad day and just gave up? Because people aren't emotionless robots and a horrible thread like this stressed someone out enough to cause an error? Because someone jumped to an incorrect conclusion and shut down discussion prematurely?

You overgeneralized ("if this is representative"), you talked about bugs like OP should be treated the same as anyone who can't boot their system after yesterday's updates. Even then, the very best that arch's staff should be doing is to try make you come up with configuration, environment information and whatever else debug data, and tell you where to create a bug report. But in above paragraph, you make it look like people's emotions are more important than technical accuracy, framed in a way which is seriously worhty of FOX news. As promised, I'm going to tell you what to do if you feel like you're getting shut down: get some data, create your own bubble and use that AUR package, don't give up on a bunch of people who are so tired of discussing taste and cosmetic adjustments. That's not what they enjoy to spend their weekends on. cheers! mar77i Sent with [ProtonMail](https://protonmail.com) Secure Email.