Re: long-standing bugs and tar pits
On 9/16/22 1:03 PM, Russ Allbery wrote: > "G. Branden Robinson" writes: > > > That said, such people define "constructively" in an odd way, as can be > > seen above; they assert that the only way they experience respect is to > > be _obeyed_. They claim that they are treated as second-class citizens > > because they are not deferred to like monarchs--or dictators. I advise > > people to be watchful for this pattern because you can be sucked into an > > energy-sapping dynamic that reduces your channel capacity as a volunteer > > and dilutes your enjoyment of (what should be) a collaborative > > environment. > > Yes, this. > > After my message clearly hit a nerve, I went back and reviewed the > debian-user threads that started this out of curiosity, and I see that it > had already reached the point of Chuck expressing his suspicions that > we're maliciously sabotaging Debian for our employers by not fixing bugs > (!!) [1]. I'm not seeing a glorious collaborative future here. > > It's okay, and even desirable, to give a chilly reception to people who > approach free software projects with this level of persistent entitlement. So Chuck Zmudzinski is on trial for hating Debian. What is the penalty? He cannot be allowed to contribute to Debian. That is the sentence you and some others are trying to impose on me. I suppose you can be allowed to have that opinion about me, but you are not the BDFL of Debian. No one is. Yet, there are people who could kick me off this list, but they have not. I will make a note of the fact that I would not want Russ Allbery to become the BDFL of Debian, because if you were, you surely would have done it by now. And you would be kicking off the list a person who thinks Debian is amazing, both the software it produces and the people who produce it. Best regards, Chuck > These folks are usually negative effort: the amount of annoyance and > disruption that they cause exceeds the value their technical contributions > could add. The ones who are willing to learn and change their behavior > will figure out why no one is willing to help them and try a different > approach. > > Free software projects are uniquely vulnerable to people who attempt to > manipulate you by making you feel like a failure for not having addressed > their specific problem. Avoiding that emotional trap is an important part > of healthy boundary setting and sustainability. > > Debian is something we build together, voluntarily and consensually. When > someone needs a break, other people carry the load, or sometimes we put > the whole thing down and rest for a bit. We don't berate each other for > not working harder. > > [1] https://lists.debian.org/debian-user/2022/09/msg00267.html > https://lists.debian.org/debian-user/2022/09/msg00297.html >
Re: How to make a positive impact by contributing
On zaterdag 17 september 2022 02:32:48 CEST Chuck Zmudzinski wrote: > Diederik, a member of the Debian Xen Team Stop thinking you need have some 'role' to contribute to a (FLOSS) project. In another part of this thread I linked to my submission to the upstream kernel. It got accepted, while for all intends and purposes I'm just a 'random guy on the Internet'. > Diederik, what do you think of the idea of finding a sponsor > to do an NMU to fix #983357? That would be a VERY bad idea. It is an upstream kernel issue and I already described how to proceed: Write an email to the upstream maintainer(s). You want to see the issue fixed? Write the damn email! What you wrote earlier gave the impression that you feel powerless. The way to change that is to take control and the best way to do it is do the work yourself. The great thing about FLOSS is that you actually can. Now go do it. That's how you can make a positive impact. Here's some additional tips (for that email): - It likely useful to add xen-de...@lists.xenproject.org to the CC list - Make your email 5 lines (80 char width) long, max 10. GKH likely receives 100+ emails a day, so the shorter your email is, the more likely it is it gets read and hopefully acted upon. - Linking to the Debian bug is useful, but make sure he doesn't have to read (any of) it by including all the needed info in those 5-10 lines. - When replying to any response, quote as selectively as you can. Addendum (based on your other/private email): On vrijdag 16 september 2022 22:03:11 CEST Diederik de Haas wrote: > On Friday, 16 September 2022 20:41:33 CEST Chuck Zmudzinski wrote: > > Please explain why you are asking *me* to do that. > > In a do-ocracy, *someone* needs to do it and it may as well be you. I've deliberately ignored/not responded to much of the discussion in the hope that at least something useful would come out of this. I have described above and earlier how YOU can make a positive contribution, but it really looks like you go out of your way to make other people do the work instead of yourself. You can still CHOOSE to make a positive contribution. Or you don't. The choice is up to you. The email message described above/earlier is about raising the issue to the upstream maintainers to make them aware of the issue and discuss the best way to fix it. So it should NOT include the patch. This would 'work around' your strong moral objections to 'stealing' Ben's magnum opus. You can ofc include something like: "Ben found that increasing the value of UEVENT_BUFFER_SIZE in include/linux/ kobject.h to 4096 fixed the issue". I like giving credit where credit is due and that would do it. In a possible later patch submission, you can add a "Suggested-by:" tag as described here: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes but as that paragraph describes, you should ask Ben's permission for that. HTH, Diederik PS: don't send me any more private emails; I'm not interested (any more) signature.asc Description: This is a digitally signed message part.
Re: Are users of Debian software members of the Debian community?
On Sat, Sep 17, 2022 at 11:12:54AM +0800, Paul Wise wrote: On Fri, 2022-09-16 at 10:13 -0400, Michael Stone wrote: 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. While the number is probably less, some people (including Debian contributors) are using Qubes (which is based on Xen) on desktops: https://www.qubes-os.org/ *I* use qubes, as well as xen on its own, which is why I'm fairly comfortable asserting that bullseye works just fine for typical use cases on both platforms. I haven't taken any particular measures to work around the bug under discussion--it's just never come up. In qubes you aren't generally working with a virtualized bare metal system (i.e., watching a bios boot screen come up on a virtual monitor after booting from an iso), you're interacting with a templated thin vm via qubes-specific I/O channels. The underlying tech may be xen, but the way it is used is different. (Conversely, when I do want that "boot a virtual bare metal system from an ISO" experience I do so on a different computer, currently via KVM and previously via virtualbox or vmware.)
