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

Re: Are users of Debian software members of the Debian community?

On Thu, Sep 15, 2022 at 06:37:03AM -0400, Chuck Zmudzinski wrote:
The difficult cost of trying to have a voice as a Debian user is *not* the commitment, it
is enduring the ad hominem attacks when I express my opinion. Of course if I cannot
overcome the stigma of the ad hominem attacks, my voice is completely nullified
by those ad hominem attacks. And they continue. Michael Stone followed me to
this list and condemned for me asking questions here on this list. There is no way
*he* considers me a member of the Debian community who has a formal voice as
a Debian user.

Since you've been complaining about how people react to your messages for quite some time, perhaps you might change the way you write your messages?


When people give you negative feedback, you announce that they are "attacking" or "defaming" you.


And the pattern continues with new messages periodically complaining
about debian, followed by "oh, I understand now" type messages, then the
same complaints get recycled again later.



There are a lot of walls of text that just don't seem to ever lead
anywhere. In the message I'm replying to you wrote 90+ lines, took the time to call me out for "attacking" you, asked some rhetorical questions, but never explained a particular problem that debian might be able to address. You want other people to read volumes but show no sign of changing based on the feedback you get, repeatedly complaining about 'bugs not being fixed' without mentioning what bugs so people could actually engage with you on why a particular bug might not have been fixed. (You did it yet again in the message I'm replying to--after specifically stating at the start of this thread that your last thread on the topic degenerated so you were going to switch lists and focus on something different!) I can't see how we can possibly improve your experience with debian until you stop the long meta-discussions about vague concerns and find a way to clearly communicate what problems we might help you to fix. If you want better results, keep your communications direct and actionable.

In fact, this is basically what you were told a year ago in one of the threads where you complained that you were being attacked:


"You've filed a new bug so make the exact problem the primary part of this bug. Don't ask of others to read a '50 page document' and expect them to distill YOUR problem themselves. Doing a copy+paste of the *relevant* part is absolutely fine."

You have now sent a message about a particular udev issue to debian-user and I replied with one immediate thought. Some more thoughts: you're using a fairly obscure configuration. Most people running interactive VMs (e.g., on a desktop with a graphical console) aren't using Xen, they're using kvm or virtualbox or just about anything else. People running Xen are much more likely to use something like debootstrap rather than going through an installer. So the number of people who 1) can duplicate the problem and 2) are likely to do so, is pretty small. The reality is that this will affect how much attention the problem gets. As mentioned several times, by several people, you have a tendancy to write enormous volumes of text. Just reading the logs of the bugs associated with your issue was exhausting. There are no concise summaries, there are no small patches to help identify/isolate an issue. (There is, for example, a 1700 line patch in 994899 which basically reverts an entire set of functionality; maintainers generally prefer minimal and well understood changes. The eventual fix from upstream corrected several issues but didn't rip out all the associated functionality to do so.) It's not enough to say that something like that fixes a problem for you, unless it's clear what the effect would be on the set of people whose systems are currently working but who might be negatively affected by the change. For your udev problem I would probably focus on why the runtime behavior is different than the installer behavior, and try to make the installer behave like the runtime. (Runtime doesn't require kernel patches, etc., so it seems unlikely those are necessary to fix the problem.) If you can isolate that to something you can express clearly and produce a patch to correct you'll probably get a positive response. If you continue to send massive volumes of roundabout reports, then complain that you aren't getting enough attention, it's much less likely that anyone will choose to spend time working with you on this.

Reply to: