[Poster is cc'd by me because he is not subscribed to the debian-project list]

On Wed, Sep 14, 2022 at 03:17:03PM -0400, Chuck Zmudzinski wrote:

On 9/14/2022 12:22 PM, Andrew M.A. Cater wrote:

People of debian-user :)

This thread does seem to be degenerating slightly into accusations and name-calling, justified or not. Without prejudice to anyone: please may
I remind you that debian-user and all Debian lists and IRC channels are subject to the Debian Code of Conduct.

It would be very much appreciated if disagreements could be resolved constructively and in a positive way. Ad hominem attacks don't help
anyone here. Taking a breath / walking away from the keyboard for half
a day might also help get a sense of perspective in any mailing list opinion difference. (And yes, I know about https://xkcd.com/386/ and
the difficulty that brings).

With every good wish, as ever,

Andy Cater

[For and on behalf of the Debian Community Team]

Thanks for this, Andy, I admit I did get caught up in behavior that appears as trolling.

As you point out, the aforementioned thread only slightly has degenerated
and I think there are some useful discussions in it despite the problems.
One legitimate topic for discussion that arose in that thread is:

Are only Debian Developers with voting rights (DDs) considered to be members of the Debian community, or are the users also members of the Debian community?

Hi Chuck,

I'm going to assume good intent and answer you as best I can. At its heart, Debian is a "do-ocracy" and you get out of it what you're able to put into
it. We're all volunteers and that has to be remembered.

"The community" in its broadest sense is the developers, maintainers, contributors and the users - everyone building and using Debian for whatever purpose. You don't normally get recognition just for using Debian but you
build up a reputation by contributing.

You don't have to be a Debian maintainer or a Debian developer to contribute. You can file good bug reports - or check reports opened by other people and reply if your experience is similar/you're using identical hardware, say, and the bug bites you. You can contribute to the Wiki, you can contribute positively to the mailing lists. You don't get a vote in general resolutions (GRs) but you're involved. "Drive by contributors" often gradually decide they want to become a Debian Maintainer. That means going through a formal process to check on the sorts of things you can contribute. From there, the step
to being a Debian Developer is relatively small. At that point, you get a formal vote on burning issues like GRs.

You can get a lot more information by looking at the wiki, the documentation for new maintainers, installing the Debian Administrators handbook - package debian-handbook .

If Debian users are also members of the community, their opinion should be valued, but what mechanism exists for the voice of Debian users to be heard in
the decisions that DDs make about the Debian Project? I ask this question because AFAICT, the users have no formal voice at all in the decisions about how the Debian Project is run. And this fact is perhaps why I am misunderstood
by some on debian-user. Debian-user seems to be dominated by the idea that
a mere user of Debian software should have no voice in the decisions, no matter
how great or how small that decision might be, that the Debian Project has to face each day. For example, a little decision: a package maintainer decides whether or not to respond to a bug report, and a big decision: the DDs vote on resolutions to determine the level of support for non-default init systems.

I'd suggest to anyone to read the mailing list archives for a while and see how they show Debian and the decision processes we have internally. https://lists.debian.org/ is a good start.

Big decisions can take a *long* time and some can be divisive: systemd discussions went on for months, sometimes with increasing rancour and misunderstandings on all sides but that was, perhaps, exceptional in
recent years.

I think Debian users should have some say, some voting power, some way
of influencing the direction of the Debian Project because in the end the long-term success of the project depends on whether or not Debian software
is continues to be useful for its users over the long term. I think if over time
Debian becomes software that is only useful to the DDs and not to a large pool of users around the world who are passionate about free software,
Debian would have failed in its mission of providing useful free software to users around the world. The point of view of users, IMHO, needs more representation in the official decisions and policies of Debian because it seems to me that the importance of providing useful software for the
many users of Debian software is not sufficiently recognized on, of all places, the mailing list for Debian users!

_Which_ Debian users? We have users all over the world, on the ISS, every continent. We've folk of all shades of politics, religion. We've got
people from every human background. Debian doesn't *just* become software that's useful to DDs - there are >200 derivative distributions and a 29
year backstory.

Debian-user is a subset of people who are interested in Debian. Some are opinionated, some are long-suffering, some are decidedly idiosyncratic -
that's all OK. It shouldn't be taken as the whole project, just the
folk who hang out on that list.

I offer this as food for though to see if the way Debian is governed can
be improved to ensure the legitimate voices of Debian users are heard. I especially would be interested to hear practical suggestions for how a vote of users on any particular issue could take place, what weight should be given
to the vote of the users relative to the vote of the DDs, how users could propose
that a change in Debian Policy be put up for a vote, and how to ensure only true users of Debian vote on any particular proposal or in the election of the
DPL, etc.

I *really* suggest you look at the mechanism of Debian consensus: it's often difficult to follow debian-vote but that's only pulling together a thousand
or so individuals, each with their own voices and legitimate interests.

"True users of Debian" - hmm, is that people who've been using and
contributing to Debian for 25 years, 2 years, 2 weeks? Sorry, I'm bemused
by this - Debian reputation goes upwards, downwards and sideways to
everybody else that contributes but it is built on contribution above all.

I understand this idea cannot be implemented soon. But would it be wrong
for someone to propose the idea that Debian users should have a formal
voice in the decisions that the Debian Project needs to face on a daily basis?

You do have a formal voice as a Debian user but it may come at the cost of commitment.

N.B. I am not subscribed to debian-project, so if those who respond could Cc me on replies, I would appreciate it. I also am not posting this to debian-user,
to which I am subscribed, to let the emotions die down there a bit and in recognition of the fact that debian-user is probably not the best place to post
this question at this time.

Debian mailing list code of conduct: ideally, you subscribe to a list rather than posting and expecting individuals to reply, not least because the
replies are then appropriately ordered and threaded in the archives of the list. https://www.debian.org/MailingLists/ refers. Most of the people who
are subscribed to the mailing lists will not cc by default.

In this case, you are a .cc addressee precisely because you have said you
are not subscribed and so I have explicitly changed my normal policy.

Best regards,

Chuck

With every good wish, as ever,

Andy Cater

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Sep 14, 2022 at 03:17:03PM -0400, Chuck Zmudzinski wrote:

Thanks for this, Andy, I admit I did get caught up in behavior that appears >as trolling.

As you point out, the aforementioned thread only slightly has degenerated
and I think there are some useful discussions in it despite the problems.
One legitimate topic for discussion that arose in that thread is:

Are only Debian Developers with voting rights (DDs) considered to be members >of the Debian community, or are the users also members of the Debian community?

You were asked to stop, and you haven't stopped--you just moved to
another mailing list. You've been behaving the same way for quite some
time, raising "questions" that repeat regardless of the answers you get,
and there doesn't seem to be any real possibility that additional
engagement will change that rather than encouraging more of the same.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,


Le 15/09/2022 à 12:37, Chuck Zmudzinski a écrit :

Obviously, my proposal would need to somehow define who are the users
that should be given a formal vote for GRs, the DPL, etc. Maybe "true users of Debian" is the wrong phrase to define it, maybe the correct idea is expressed
by "contributor with voting rights." Maybe the voting developers can
nominate contributors who are not developers who should be given voting rights, and if the person nominated receives a simple majority, or some higher
majority like 2/3, then that person gains voting rights even though that person
is not a developer. The theory behind my proposal is that there is a diversity
of viewpoints that stems from a diversity of roles within the project. If the voting members are restricted only to the contributors who volunteer for
the role of developer, then the full diversity of the Debian community is
not reflected in a vote that only comes from the pool of formal developers.

I would just like to point out that it is possible (and it has been
done) to become a Debian Member with voting rights without a developer
role. This is what we call "Debian Developer, non-uploading" (or Debian Member).

You have to be a contributor, still, and follow the New Member process -
more information is available at
https://www.debian.org/devel/join/newmaint

I subscribed to the debian-project list for the time being so you can reply on-list
from now on.

ACK :)

Cheers,

--
nodens

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Chuck Zmudzinski <[email protected]> writes:

The theory behind my proposal is that there is a diversity of viewpoints
that stems from a diversity of roles within the project. If the voting members are restricted only to the contributors who volunteer for the
role of developer, then the full diversity of the Debian community is
not reflected in a vote that only comes from the pool of formal
developers.

I think it depends a lot what the viewpoints are being diverse *over*. If you've formed a group of people to go pick up litter, it's not helpful to
have a diversity of opinions about whether or not litter should be picked
up. That is just silly. And, somewhat more on point, it's not helpful to
have a bunch of members who have no intention of going out on the street
and picking up litter, but who have strong opinions about how other people should do so. This is not useful diversity.

There are numerous Linux distributions with different viewpoints about how
to make a Linux distribution. That's diversity, real diversity, in terms
of distribution goals and structure. It's the kind of diversity that
involves completely independent organizations making completely
independent decisions with different financial structures, different
founding principles, and so forth. As a Linux user, you can explore that diversity by picking and choosing which distributions you install and use.

Within any given project, including Debian, we're all trying to do
something together, which inherently requires some amount of agreement and consensus. At some level, this is the opposite of a diversity of opinion.
We have to roughly agree on a course of action, at least at some level and
with some rough, in order to make forward progress. One of the things
that's helpful to avoid endless decision paralysis, or to avoid a bunch of people who are not in a position to do the work voting for things the
people who are doing the work don't want to do, is that we ask everyone
who is voting on major decisions to have significant skin in the game.
The implicit assumption behind GR voting is that to some extent you're
then going to go help implement what we all voted for, because we're the
only people who can.

The voters are the same group as the implementors. We're using voting to
help guide consensus among the same group that has to do the work. If no
one does the work, the GR is useless and pointless and there's no reason
to have held it. That tends to significantly inform our voting. It's something that I think about with every GR.

To make that concrete, you can hold as many GRs as you would like saying
that every bug in Debian with a tested patch should be applied and
uploaded, and it will accomplish precisely nothing. Changing who votes on
such GRs is useless; the whole theoretical model behind such a vote is
wrong. Work happens in Debian because someone does it. Voting doesn't
change that; what changes that is more people doing work.

If you think a package is being neglected by its maintainer, we have
processes for that, but they mostlly require that you, the person who
wants to make a change, step up and be the maintainer. If no one is
willing to step up and be the maintainer, the package will continue to be neglected. Voting is not a magic spell.

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.

This is Michael thinking you're being annoying and wasting people's time
and telling you so, while warning other people who don't follow
debian-user that arguing with you may be futile. It has nothing to do
with whether or not he considers you a member of a community. I can
assure you that he'd say the same thing to a DPL if he thought they were
being annoying and futile to argue with.

--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Chuck Zmudzinski wrote:

I have read much of the documentation online about how Debian understands

itself, but I have never heard the term "do-ocracy" before.

As I understand, it is an informal term, as such I don't expect to
find it in formal documents. I read it as meaning "those who do the
work run the show". I believe that is a sensible rule for a community
of volunteers.

Obviously, my proposal would need to somehow define who are the users

that should be given a formal vote for GRs, the DPL, etc.

I do believe that being open to listening to other people's advice is
a virtue, and that the Debian project should definitely listen to its
users, but I don't think that this should necessarily translate into
voting rights.

Besides, voting isn't always the best way to make decisions. On
technical matters it is usually better to let it to those who know the
subject best, and those are normally the people who routinely work on
it -- which brings us back to the "do-ocracy" concept.

Also, please consider that while voting rights are restricted to
Debian members, discussions are usually open to everybody, so if you'd
like to contribute to Debian's decision-making process, you already
can.

I actually, after some fruitful

discussion with some of the people on debian-user, tentatively came to the conclusion that the fact that Debian is created by volunteers is probably one of the biggest *disadvantages* of Debian software.

If you could explain concisely how you came to that conclusion, I'd
like to read it. My view is quite the opposite but I suppose that
learning a different way of thinking about this issue may help me
widen my perspective.

you get out of Debian what you put into it.

In fact, I believe I received much more than I gave, and I hope I'm not alone.

Gerardo

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Chuck Zmudzinski <[email protected]> writes:

To put it in the most brief terms, I come to that conclusion based on
what many people are telling me: Debian maintainers cannot fix bugs in software because they are just volunteers. That explains why I almost
always am at least annoyed by one or two bugs when running Debian
software, and sometimes after an update the computer is totally unusable until I can debug it and find the fix, because volunteers don't have the
time to do it for me. That is what most everyone on debian-user is
telling me. Do you disagree with what they say?

Also, in my experience, these bugs and catastrophic failures caused by updates of a supposedly stable release happened *much* less often when I
used software that is written by paid developers.

So let's see if I've got this right. You don't like Debian's governance structure or its constitution. You don't like that it's a volunteer
project. You think the software is lower-quality than software maintained
by paid developers. It has a bunch of bugs that annoy you that you don't
think you can get fixed. And you don't feel welcome in the community.

You... do realize that you can just not use Debian, right? It's okay to
use another Linux distribution that suits you better! This is an entirely consensual relationship! We won't make you use Debian, I promise!

I'm all for sticking around and trying to fix things that you think are
broken, but these aren't some minor disagreements. These are some really foundational mismatches. You seem to like Debian except for... literally everything about how the project is organized and run.

There are a lot of other Linux distributions out there with different philosophies and different organizations, and it's not some sort of
betrayal to go look at a different one. No one wants you to be unhappy
and frustrated, including everyone involved in Debian!

You could, for example, go give Red Hat money and then get that higher
quality software from paid developers that you want. They'll give you a support contract and you can tell them what bugs you want fixed, and
they'll give you a quote, and you can give them money, and they'll fix the
bugs that you want fixed, and you can stop investing all this time and
effort in writing extremely long mail mesages to volunteers to convince
them that volunteering is bad, actually.

Or maybe the problem is that you want to be able to tell people what to
do, but you don't want to have to pay them? If so, uh, good luck with
that!

--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, Sep 15, 2022 at 06:17:02PM -0400, Chuck Zmudzinski wrote:

To put it in the most brief terms, I come to that conclusion based on what many people are telling me: Debian maintainers cannot fix bugs in software because they are just volunteers.

That statement is incorrect. People _can_ and _do_ fix a lot of bugs when
they have time. There are a lot of DDs/DMs/contributors fixing a lot of bugs on a daily basis
for that matter. You could consider taking a look at -devel-changes ML if you'd like to.

That explains why I almost always am at
least annoyed by one or two bugs when running Debian software, and sometimes after an update the computer is totally unusable until I can debug it and find
the fix, because volunteers don't have the time to do it for me. That is what most everyone on debian-user is telling me. Do you disagree with what they say?

Well, sometimes bugs do sit around for a bit, yes; but you are presenting it in a much way that it makes the situation look worse than it actually is.
The resolution is quick quite a few times (to my
experience and I am a DD myself) but yes, sometimes they do sit around for a while.

In that case, it is nice to file good bug reports (as Andy told you) and if you have a
patch, that's even better. You could consider to ping maintainers after a week or so if
you think it is important. And if you think something very critical is broken, you could
even raise the severity of the bug, I don't see a lot of problem with it.

And yes, sometimes the maintainers of a package _can_ be AFK too, this is volunteer work
after all. Someone might be on a vacation, or in a conference, or travelling, or busy with RL
and seeing your BR on an immediate basis isn't a possibility.

Also, in my experience, these bugs and catastrophic failures caused by updates
of a supposedly stable release happened *much* less often when I used software
that is written by paid developers.

Fine, but what do you propose to do here? Pay all DDs for fixing bugs? Who will manage the finances/funding?
What if a bug report is critical and someone is unwilling to pay for a fix? What if someone needs a break for
whatever reason? -- have you considered to give a thought about these?

Also, I'd like to say that calling out Debian contributors with "Hey, you are doing a horrible job" is
a negative thing for us to hear as well. You said that you got a few negative replies, which you are annoyed
with, this goes both ways, really.

--
Best,
Nilesh

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEPpmlJvXcwMu/HO6mALrnSzQzafEFAmMj98MACgkQALrnSzQz afEQXRAAnKuenBIhZkAKiREgb617P4Gd0tPiwqgwVLWvDZCO/mhuDzxWinaq+SzN 9cuDmIfGOuP/YWtMaVvpvKtMXMEN8/4nlrDfeE5rV+q0OjU3sljW+/m0PvE/mcMU sHTxBWTmo89eBl+MRyb4LphbVdmM77v35uK61gbq2gZs/DE2loMxzU64EfCNGTZm GpYLkJhMW74/cg2EjAJWY9JL9K1gfPeaz1vIVoJdpLlStFX7i2NmdD2wn8IBprCY oz6T3z4IHQqYid8c7G1nTkX6NxsrtD7W9e6VxkLLmajt/A4bcwNvW2loxloyUVeK L3qkA7IXe9N4iftyP17jwaaRdS7Xj63tagWsiMrJW0Z55ts7YZOFEltXXFDf5ZXb uzUbUHfWKJGZYV44oU6OgDuv8Pk2vrGpItvCi8ZJouYwNe6MmD4HNuQQiTTfsuFn hWWVbsBUcjj8JqXoE5QuGI7TBH7CL7bNMjL2dj9vlxSvCktQpCJkmM4jAiWkxaKz he4qNrcP7JxzGvRWSXLqUqG43eolGpckMbACCs2iOg3U2ZjBqtvzFLm2ufgxVHj+ C0vxgfvKH4EEGMtN/+l2LvprQwpm9ekgYsMfdBN6gOM41Sw19BFA76sxThMOXzYG WFaHHyAgPzLKfmkyclGMFdZaje+GPeFAfB0XR3desnIuftW5i/I=
=60xw
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, Sep 16, 2022 at 08:47:19AM -0400, Chuck Zmudzinski wrote:

On 9/16/22 12:12 AM, Nilesh Patra wrote:

On Thu, Sep 15, 2022 at 06:17:02PM -0400, Chuck Zmudzinski wrote:

bugs are important. I am not a DD so my bugs are not as important to the maintainers who have a greater responsibility to respond to a DD's bug than to an unknown user's bug. That is the way it should be. No problem here, and please no one reply and say I am complaining. I am not. I am just seeing
how things work at Debian and I think they work fairly well.

Hi Chuck,

*Just because you're a DD* is not a priority call for bugs. At least one
of the bugs you reference is for Xen and seems to have bounced between
Debian and kernel devs. and still, perhaps, not to be fixed, for example.

Xen is a much lower priority than it used to be when it was the first hypervisor in common use. There are fewer maintainers _anywhere_ with
deep knowledge of Xen. If the bug with Xen keyboard doesnt' get fixed
quickly in Debian, it may be bacause there isn't a maintainer / there
are other higher priority bugs / it genuinely should be fixed upstream.

If you know a fix - you can talk to the Xen maintainer in Debian, you could submit a patch, you could ask them if they want to work with you to see
it fixed. If they say it's a wishlist bug / they have higher priorities on their tiem - you can still help.

You can politely ask the Linux kernel maintainers similarly. You can ask the Linux Foundation at xenproject.org if the bug is still there in their version. It's a "do-ocracy" that may rely on you to chase.

I reiterate my suggestion to you to go and read list archives / documentation
/ the Codes of Conduct to get a better picture of who you are asking, what
you are asking for and generally "How Debian works". Long messages to debian-user and debian-project may not help here as an initial approach.

Russ and Wouter and others have made suggestions as to how to approach
people in a better way so that they will listen to you and read what
you have to say more readily.

With every good wish,

Andy Cater

In that case, it is nice to file good bug reports (as Andy told you) and if you have a
patch, that's even better. You could consider to ping maintainers after a week or so if
you think it is important.

Thanks for the advice. I think a week is way to short. They probably would think I am a nag and a troll if I did that. I usually wait six months and they
still ignore the bug sometimes.

And if you think something very critical is broken, you could
even raise the severity of the bug, I don't see a lot of problem with it.

And yes, sometimes the maintainers of a package _can_ be AFK too,

For six months?

this is volunteer work
after all. Someone might be on a vacation, or in a conference, or travelling, or busy with RL
and seeing your BR on an immediate basis isn't a possibility.

Also, in my experience, these bugs and catastrophic failures caused by updates
of a supposedly stable release happened *much* less often when I used software
that is written by paid developers.

Fine, but what do you propose to do here? Pay all DDs for fixing bugs? Who will manage the finances/funding?
What if a bug report is critical and someone is unwilling to pay for a fix? What if someone needs a break for
whatever reason? -- have you considered to give a thought about these?

You misunderstand me a bit here. If I wanted to propose the idea of
paying Debian volunteers formally, I would have not have done it
on debian-user. The comments so far make realize that is not how
Debian people want to handle the problem of maintainer burn-out,
which seems to be the complaint of some maintainers.

Also, I'd like to say that calling out Debian contributors with "Hey, you are doing a horrible job" is
a negative thing for us to hear as well. You said that you got a few negative replies, which you are annoyed
with, this goes both ways, really.

You failed to notice the messages when I thanked the maintainers
when they fixed the bug. Please judge me on the facts, not just the
parts you pick out that make me look like a terrible person. IIRC,
that would be against the Debian Code of Conduct.

Best regards,

Chuck

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994899#5

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

https://lists.debian.org/debian-user/2021/09/msg00785.html

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.

https://lists.debian.org/debian-user/2022/08/msg00370.html

https://lists.debian.org/debian-user/2022/09/msg00267.html

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:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994899#10

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, Sep 16, 2022 at 08:47:19AM -0400, Chuck Zmudzinski wrote:

On 9/16/22 12:12 AM, Nilesh Patra wrote:

On Thu, Sep 15, 2022 at 06:17:02PM -0400, Chuck Zmudzinski wrote:

To put it in the most brief terms, I come to that conclusion based on what
many people are telling me: Debian maintainers cannot fix bugs in software
because they are just volunteers.

That statement is incorrect. People _can_ and _do_ fix a lot of bugs when they have time. There are a lot of DDs/DMs/contributors fixing a lot of bugs on a daily basis
for that matter. You could consider taking a look at -devel-changes ML if you'd like to.

That explains why I almost always am at
least annoyed by one or two bugs when running Debian software, and sometimes
after an update the computer is totally unusable until I can debug it and find
the fix, because volunteers don't have the time to do it for me. That is what
most everyone on debian-user is telling me. Do you disagree with what they
say?

Well, sometimes bugs do sit around for a bit, yes; but you are presenting it in
a much way that it makes the situation look worse than it actually is.
The resolution is quick quite a few times (to my
experience and I am a DD myself) but yes, sometimes they do sit around for a while.

That's easy to explain why your bugs are fixed quickly. You are a DD, so your bugs are important. I am not a DD so my bugs are not as important to the maintainers who have a greater responsibility to respond to a DD's bug than to an unknown user's bug. That is the way it should be. No problem here, and please no one reply and say I am complaining. I am not. I am just seeing
how things work at Debian and I think they work fairly well.

Please stop with your passive-aggressive rhethoric.
Claiming that we don't care about equally our users is … inappropiate and greatly insulting
to the contributors (regardless of their status in the project).

You need to stop that. Right now.

In that case, it is nice to file good bug reports (as Andy told you) and if you have a
patch, that's even better. You could consider to ping maintainers after a week or so if
you think it is important.

Thanks for the advice. I think a week is way to short. They probably would think I am a nag and a troll if I did that. I usually wait six months and they
still ignore the bug sometimes.

And if you think something very critical is broken, you could
even raise the severity of the bug, I don't see a lot of problem with it.

And yes, sometimes the maintainers of a package _can_ be AFK too,

For six months?

Even if it six years, a maintainer has absolutly the right to ignore any report,
be it mine, the DPLs, from someone else or yours. Remeber, unless you pay them, they do not owe you anything.

The feedback given to you that they way you interacted with the project needs to
improve, but your reaction was *not* to consider this input but to feel insulted instead.

Then you escalated to -user, and as this dis not yield the result you wanted, you finally escalate to -project, and people are trying hard to explain here that there is some inappropiateness in your way of interacting with the project.

--
tobi

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, Sep 16, 2022 at 08:47:19AM -0400, Chuck Zmudzinski wrote:

On 9/16/22 12:12 AM, Nilesh Patra wrote:

Well, sometimes bugs do sit around for a bit, yes; but you are presenting it in
a much way that it makes the situation look worse than it actually is.
The resolution is quick quite a few times (to my
experience and I am a DD myself) but yes, sometimes they do sit around for a while.

That's easy to explain why your bugs are fixed quickly. You are a DD, so your bugs are important. I am not a DD so my bugs are not as important to the maintainers who have a greater responsibility to respond to a DD's bug than to an unknown user's bug.

That's a completely wrong interpretation that you are drawing here. No, that's not really the reason here.
The reason is rather that people _do_ work on bug reports regardless of
who reported them, but you somehow do not want to acknowledge the fact that package maintainers do work on bug reports.

That is the way it should be.

No, that should not be that way, it'd be _very_ wrong. If that was actually the case we would be violating the debian social contract point 4

"Our priorities are our users and free software"

No problem here, and
please no one reply and say I am complaining. I am not. I am just seeing
how things work at Debian and I think they work fairly well.

You are seeing it in completely incorrect ways.

And if you think something very critical is broken, you could
even raise the severity of the bug, I don't see a lot of problem with it.

And yes, sometimes the maintainers of a package _can_ be AFK too,

For six months?

Yes?
What if a package maintainer runs into a medical emergency, or some family? Or someone
is into completing their PhD, let's say?

Aren't we humans after all?

FWIW, even my bug reports have been lying to take actions for long times, so
it is not just you.

this is volunteer work
after all. Someone might be on a vacation, or in a conference, or travelling, or busy with RL
and seeing your BR on an immediate basis isn't a possibility.

Also, in my experience, these bugs and catastrophic failures caused by updates
of a supposedly stable release happened *much* less often when I used software
that is written by paid developers.

Fine, but what do you propose to do here? Pay all DDs for fixing bugs? Who will manage the finances/funding?
What if a bug report is critical and someone is unwilling to pay for a fix? What if someone needs a break for
whatever reason? -- have you considered to give a thought about these?

You misunderstand me a bit here.

What was your idea then? What solution do you intend to propose for:

"""
Also, in my experience, these bugs and catastrophic failures caused by updates of a supposedly stable release happened *much* less often when I used software that is written by paid developers.
"""

Also, I'd like to say that calling out Debian contributors with "Hey, you are doing a horrible job" is
a negative thing for us to hear as well. You said that you got a few negative replies, which you are annoyed
with, this goes both ways, really.

You failed to notice the messages when I thanked the maintainers
when they fixed the bug. Please judge me on the facts, not just the
parts you pick out that make me look like a terrible person.

And maybe you failed to notice that the statements you made on this thread and also
on debian-user are negative statements, and just saying a thanks does not make it all good again.
Please judge procedures in debian on the facts,
not just the bug reports you pick out to make us look like terrible volunteers.

At this point, you need to make peace with the fact that you don't get to order people into doing something for you.
I'll not engage on this thread anymore, I am so done.

--
Best,
Nilesh

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEPpmlJvXcwMu/HO6mALrnSzQzafEFAmMkfU8ACgkQALrnSzQz afE0axAAiRDhkmreteOGBGuykxW+w6ce1mkk0arwQ5HGDo1EdI6Vx8T3cJH/lD40 AKITZFXsaJB9nlhPQD+2MAOnlrCyz8FQCmlItNHQ/Qv5XDiad2Ot2vtoeD6+/VNl W0wHYl3vvFh14ysCZVfaWXznXfwCDSMWCM0fHuymQ3xjKza/vZTwATK30Kb78K9Y ZTfCshCckIshzWRhaJ+m795+qBD4zUT/EcJDPuf/CdhM1rt9aRnc7KDb/+xk3EQm Q7WI4cnI6gQwzyHFh6Ac0ymbzMDYMJn9I4qRNEWytig/JvovOPSxLgFQjCSX5D27 E35Inz/Dag0Swqu8PcBVpfJCFW79+ZehOsrnQju1hZ3ZgYEbAa/pOMaz/3Nj4EAV G9QX0XifOGdSL966/CToYqqbW5TsGbFcWV6F/LVBZi/KhooKzYUiE4x9uWT6xySR Wspt2eCAspOtRxXPeT7YlOMs33Mskebb1ZwOCScJzgvFxRcpquFTviZRQq2KmJ2z vqSVJAT9MqKzwTlUJiHuhYsBP8Put21lniGTF53JQ64kxmjoDaTRHWGMmUt7Ckxn OF2BU4jXHvfMUEEUn08o/mUn2eWlruNKGj4OsmV7vyvqFZIefP95cLnVGE2yPVqd /UzI9HHR5sxzTuMARPr6gXDqS7WaNUNDgo1bN7JXrWPEi7tKBt0=
=7ohN
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, 16 September 2022 16:37:50 CEST Chuck Zmudzinski wrote:

the Linux kernel accept a patch to fix Debian #983357

Has the patch every been proposed to upstream?
If not, then send one with 'git send-email' to the ones listed for the file in question, which can be obtained via 'get_maintainer.pl':

$~/dev/kernel.org/linux$ scripts/get_maintainer.pl include/linux/kobject.h
Greg Kroah-Hartman <[email protected]> (supporter:DRIVER CORE, KOBJECTS, DEBUGFS AND SYSFS)
"Rafael J. Wysocki" <[email protected]> (reviewer:DRIVER CORE, KOBJECTS, DEBUGFS AND SYSFS)
[email protected] (open list)

If you've never used 'git send-email' before or send patches to the upstream kernel before, these links may be off help:
https://git-send-email.io/ https://www.kernel.org/doc/html/latest/process/submitting-patches.html

HTH
-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCYySx+gAKCRDXblvOeH7b blNBAQDc8EBh8FhzEm33vnQh1nDEf5QcQ7oRSFMv2wojrDz42QEAwWZ2a0hxdvLn 2vQ8vfh3juUQ9bZBHcBeqToPniJ05Ao=
=biAK
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, Sep 16, 2022 at 01:54:09PM -0400, Chuck Zmudzinski wrote:

On 9/16/22 10:13 AM, Michael Stone wrote:

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.

I thought Debian was free and I can use it that way if I want
to, and that is how I understand Debian's philosophy of free
software. Do you understand it differently?

unbelievable

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, 16 September 2022 20:41:33 CEST Chuck Zmudzinski wrote:

The patch is written by Ben Hutchings, a kernel developer.

Anyone can send a patch for inclusion in the upstream kernel: https://lore.kernel.org/all/[email protected]/

IOW: you don't need to have some special 'role' to do it.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983357#97

I don't think I can sign-off on a patch written by Ben Hutchings.

You shouldn't use a Signed-Off 'tag' without someone explicit permission.
You can send the exact same patch with only your Signed-Off tag (required for patches submitted to the Linux kernel) though ...

As you can see from the Ben's message, the only question is
whether the buffer should be increased to 4k or 8k. I tested
and 4k was big enough for the Xen virtual keyboard, but Ben
also though that the "correct" value to increase it to might
be 8k, which matches a buffer size in udev. So we should work
out that question before submitting upstream, don't you think?

What you can do instead of sending a formal patch is send a normal email
to the persons/lists I mentioned earlier with a *short* description of the problem (with a link to the bug report) and ask the upstream maintainers
what to do about the problem and whether the limit should be increased
(in their opinion) to 4k or 8k and whether they think it should be done
at all in that particular source file or whether a different approach should
be pursued and which that is.

If the patch was (really) substantial and written by someone else (Ben),
then it's (way) better form to ask for permission to send it upstream.
In this case, it's only a tiny change (1 'word'), so 'stealing' his patch should be fine :-)

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.

You are also well suited to verify whether a change to 8k would also produce the desired fix or an alternative fix if the upstream maintainers would
prefer that.

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCYyTWfwAKCRDXblvOeH7b blFpAP9Dtp+rrTPR09vPTrZ/gUSZTv2R9+WHZCMrhsQ6BX2vxgEAo4fPSmew4U9U VNo3Mcviw+cp1ejys2gqr2e0j552WAg=
=O3Nz
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
On 2022-09-16 at 16:03, Diederik de Haas wrote:

On Friday, 16 September 2022 20:41:33 CEST Chuck Zmudzinski wrote:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983357#97

I don't think I can sign-off on a patch written by Ben
Hutchings.

You shouldn't use a Signed-Off 'tag' without someone explicit
permission. You can send the exact same patch with only your
Signed-Off tag (required for patches submitted to the Linux kernel)
though ...

It's been quite a few years, but last I remember seeing this discussed
on the LKML, I think the upshot of that discussion was that
Signed-off-by: for kernel patches is intended to indicate that the
indicated person (who should be the same person adding the tag) is
certifying that the code being submitted is licensed in such a way that
it would not conflict with the license terms that cover the Linux kernel.

In practice I think it tends to be used for other purposes (instead or
as well), but I believe I've seen it stated that that's the core intent
of the tag.

If that's not correct, I'd be glad to be corrected on that front and
learn what the intent and scope of that tag actually are, but it's been
my understanding for - as I said - quite a few years now.

--
The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw


-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEJCOqsZEc2qVC44pUBKk1jTQoMmsFAmMk4GMACgkQBKk1jTQo MmsSCg/9HXy1oqzqngsmyIaVu322EaN56yWhBstjIUb5IIGL8CbZ1FEq1NJwgIZC GlUe8iD29SpwjQXbRJV5+9K/Stl6kCdU1pENmeul4DctlGST/iET71mfxj0Ib+DS cZdZWJly0/5fsMQTUB5yQBiMLB7pj13WYm5ZgM7urJ+VmyBMpkkJT5yRKMJVE9bO B6mIeVLjBmqstuYVojIbtml0eIPXqVCIJQVpPcJpILwRmDwK4yrSruFdbLUiN1Rb mB+i5y3HrNnudtiAfduqGyjpdUXJArcqmO5lrvA91L1x6x0lZ8GIaX0tTyU537I6 VHLXWqYt4JH44UK/dZwMwVVVdRcv7rlosOtsG2LXSKsRa8zZlDnBQDcb8XJl3rTk t8Fjm5500WZze/TETsuA9LD/AgtTGhbAvOYuFwb3SZVKCk2OnRt0jAXzHUR+6tMl UtrUnmfPxamWkgTqZkkbg8JeRITH4zRGtRB+nqrn68qbH09RMv/4Jg73SUnIoZdL +9WrLrBQjLW8S3NF1WED7IYyt8YJpPgOubl2aKZ2Y3cOO/pS44p4lvj5latMUnuk jGVnIQg0nFG0Q4cPOsuIigqv7+4zj5R+kZ+NPVHbBfH209gTa+BFU0tMgwEH69Pc gdfMwNL5X68lTqqeYciu7XDVZSFV

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/

--
bye,
pabs

https://wiki.debian.org/PaulWise

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAmMlOzMACgkQMRa6Xp/6 aaN99A/+M2hCeViG/GIlXM9O5O+v0r81yfAUOwYIjXpMMB0IriSIvwEPgu2Mvtmi S+BXz4CeT8tWB6+j7Z/Hrd+1iNb8Hax81EldbbNQbuyHVRTtoAiszleWCXWMQXAJ +hrN5W1MHp7BoJ5gtgNPhh6M89w9qxlL8Wa1I9j/ge3/io/8yvjUg2l6aDtyUDkk KxR7QkKpoOVPEyzskdGFnzimKv3scaBXfwYucZ6Q8cQbfhn23ZmMtpf/og/jSO4j m9hF547XQbo7LoFC1/WkoI1d8UPRy/w+pZ4i2oEUWW02TX4kvWoEzurB6WFPBvzD Pe794kiSXYhMLZprVvAfT/TZRWtPfD+5/8MeNhf7paqJTl0moeFQpBKVPoamhJNn q2/9liw3nVIvnNzcXb3FXH4ZYW/500Op5xrhMmpRK/yx5eJeS9VFqE+FAmuT5zmL Egrb62fdHpshJ0UC/pt5U9LlPFMvlnxIkQ5CCBYsmlgzsMHk9GhyVmLoHCefaewx wG33SriBfHXKPGyHqUckgEf67P0iq+mDCbnUEvcZqn0Tc5FXo5X9sA0+ZKMMjpJ2 2Z06AYTGNcdWVZv2FEeltKqGR2PWOce2lY0UMIpNzjYYltKpZicR1PDK9vYnswP/ n+9E6AAZ5YzT+TuhDJ68oiYpmZ5KqFDW62QtTgDV4AqOnVBf/VU=
=teek
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)