Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.project > #12905 > unrolled thread

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

Back to article view | Back to linux.debian.project

Contents

  Re: Are users of Debian software members of the Debian community? Gerardo Ballabio <gerardo.ballabio@gmail.com> - 2022-09-15 18:10 +0200
    Re: Are users of Debian software members of the Debian community? Russ Allbery <rra@debian.org> - 2022-09-16 02:40 +0200
    Re: Are users of Debian software members of the Debian community? Nilesh Patra <nilesh@debian.org> - 2022-09-16 06:20 +0200
      Re: Are users of Debian software members of the Debian community? "Andrew M.A. Cater" <amacater@einval.com> - 2022-09-16 15:40 +0200
        Re: Are users of Debian software members of the Debian community? Diederik de Haas <didi.debian@cknow.org> - 2022-09-16 19:30 +0200
        How to Move an Issue Forward When there is no Energy Sam Hartman <hartmans@debian.org> - 2022-09-16 21:20 +0200
      Re: Are users of Debian software members of the Debian community? Tobias Frost <tobi@debian.org> - 2022-09-16 16:30 +0200
      Re: Are users of Debian software members of the Debian community? Nilesh Patra <nilesh@debian.org> - 2022-09-16 16:30 +0200
        long-standing bugs and tar pits (was: Are users of Debian software members of the Debian community?) "G. Branden Robinson" <g.branden.robinson@gmail.com> - 2022-09-16 18:30 +0200
          Re: long-standing bugs and tar pits Russ Allbery <rra@debian.org> - 2022-09-16 19:10 +0200
            Re: long-standing bugs and tar pits <tomas@tuxteam.de> - 2022-09-18 09:20 +0200
            Re: long-standing bugs and tar pits Jonathan Dowland <jmtd@debian.org> - 2022-09-21 08:10 +0200
          Re: long-standing bugs and tar pits (was: Are users of Debian software members of the Debian community?) Jonathan Dowland <jmtd@debian.org> - 2022-09-21 08:10 +0200
    Re: Are users of Debian software members of the Debian community? Diederik de Haas <didi.debian@cknow.org> - 2022-09-16 22:10 +0200
      Re: Are users of Debian software members of the Debian community? The Wanderer <wanderer@fastmail.fm> - 2022-09-16 22:50 +0200
      Re: How to make a positive impact by contributing Diederik de Haas <didi.debian@cknow.org> - 2022-09-17 18:10 +0200

#12905 — Re: Are users of Debian software members of the Debian community?

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

[toc] | [next] | [standalone]

#12906

Chuck Zmudzinski <brchuckz@netscape.net> 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 (rra@debian.org)              <https://www.eyrie.org/~eagle/>

[toc] | [prev] | [next] | [standalone]

#12907

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#12909

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
> 

[toc] | [prev] | [next] | [standalone]

#12916

[Multipart message — attachments visible in raw view] — view raw

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 <gregkh@linuxfoundation.org> (supporter:DRIVER CORE, 
KOBJECTS, DEBUGFS AND SYSFS)
"Rafael J. Wysocki" <rafael@kernel.org> (reviewer:DRIVER CORE, KOBJECTS, 
DEBUGFS AND SYSFS)
linux-kernel@vger.kernel.org (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

[toc] | [prev] | [next] | [standalone]

#12918 — How to Move an Issue Forward When there is no Energy

[Multipart message — attachments visible in raw view] — view raw

>>>>> "Chuck" == Chuck Zmudzinski <brchuckz@netscape.net> writes:

    Chuck> Debian processes: AFAIK there is no process for a user to
    Chuck> resort to when an important bug has been ignored for over a
    Chuck> year except to make some noise on mailing lists like
    Chuck> debian-user and debian-project. What would you suggest as a
    Chuck> better process to handle cases like #983357?

TL;DR: Maintainers do not have to work on any particular problem, but
 they do not get to block others' work.  First step is to figure out the
 fix for a problem, propose the fix, and eventually get to an NMU
 proposal.
 
Hi.
I agree with Branden that engaging with Chuck may not be the most
productive use of my time.
However, I think the above question is a great one, and regardless of
whether my answer is useful to Chuck, I think  it might be generally
useful.

The first step is to find a solution for Debian.
If the problem is an upstream problem, often the best answer for Debian
is to fix it upstream.
But until  there's someone who believes they know what the solution is,
the problem is not a process problem, it's a manpower problem.

Sometimes problems with multiple fixes possible are particularly
difficult as has been pointed out in this thread.
And yes, relevant maintainers may have opinions.
But there are no process obstacles to someone else learning about the
software, learning about the trade offs, and making a recommendation.
Sure, it might be hard work.  Learning Xen, the kernel, and trade offs
between them isn't going to be a short afternoon task by any stretch.
But if you have the relevant development skills, and care enough, you
can learn those things and come up with a proposal.

If you as a user aren't in a position to figure out the solution, there
are a few things you can do:

* Make sure there is a good bug report
* If you could test changes or work to collect diagnostics make that
     offer

* If you're willing to pay for someone to work on the issue, that would
  be good.  Debian does not have a process to track or deal with such
  offers, and so I don't have specific advice on how to make an offer to
  fund development of a particular fix that would be helpful.

But if there is a patch waiting that someone knowledgable believes is
the right fix for Debian,  then things can eventually move forward.
People have pointed out that maintainers (and developers) do not need to
respond to any given bug.
That's true, but maintainers and developers  do not get to block work
either.
If there's a patch that a maintainer hasn't had time to review,
eventually it would be appropriate to prepare an NMU for the package
incorporating the patch.
Anyone with the relevant skills can propose an NMU.  You don't need to
be a DM or a developer.
You just need to understand Debian packaging, understand the software,
and understand the fix.
If you are not a DD or a maintainer of the package in question, you need
to find a DD to sponsor the NMU.
The same process can be used to request sponsorship of a NMU as for
sponsorship of another upload.

[toc] | [prev] | [next] | [standalone]

#12911

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

[toc] | [prev] | [next] | [standalone]

#12913

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#12914 — long-standing bugs and tar pits (was: Are users of Debian software members of the Debian community?)

[Multipart message — attachments visible in raw view] — view raw

At 2022-09-16T19:12:40+0530, Nilesh Patra wrote:
> On Fri, Sep 16, 2022 at 08:47:19AM -0400, Chuck Zmudzinski wrote:
> > 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.

As a person of gray Debian beard (but of sufficiently low profile to
have been forgotten about as a developer), I encourage diligent
volunteers to _not engage_ with people who, whether intentionally or
not, seem determined to increase the amount of friction in processes and
to make themselves into tar pits for anyone who attempts to engage with
them constructively.

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.

I think we can take substantial value from basic game-theoretic models
of behavior: if a person defects more than they cooperate, don't play
with them.  We should ask ourselves, what does Chuck Zmudzinski
contribute to raising Debian's barn?[1]  The answer isn't necessarily
"nothing"; maybe it's "application of an angle grinder to the base of an
erect load-bearing post".

Bugs can take a long time to get fixed and sometimes you have to do it
yourself.  For your amusement and as a case in point I refer the reader
to one I had forgotten about for many years.

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=243238

Among other things, Debian is a software engineering organization.  We
can benefit ourselves and our community by becoming better software
engineers.  And indulging in "simple sabotage" of production less.[2]

I would emphasize that the list in that oft-cited resource is not an
enumeration of activities that must be avoided at all costs in all
circumstances.  I find it useful instead as a diagnostic tool in the DSM
sense; for example, if you find a person doing at least two of these 16
things at least once in every meeting (or some applicable time
interval), then they may be functioning as a drag on production--even if
they see themselves as heroically frustrating the rolling Panzers of the
wicked Axis power that is the Debian Project.  The obvious defects of
the most vilified regimes of the 20th century were that they had too
much anarchism, too much democracy, and left too much to individual
initiative.  Imagine the tragedies that could have been averted if
they'd had a BDFL like Chuck Zmudzinski.

Regards,
Branden

[1] https://en.wikipedia.org/wiki/Barn_raising
[2] https://www.businessinsider.com/oss-manual-sabotage-productivity-2015-11

[toc] | [prev] | [next] | [standalone]

#12915 — Re: long-standing bugs and tar pits

"G. Branden Robinson" <g.branden.robinson@gmail.com> 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.
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

-- 
Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>

[toc] | [prev] | [next] | [standalone]

#12929 — Re: long-standing bugs and tar pits

[Multipart message — attachments visible in raw view] — view raw

On Fri, Sep 16, 2022 at 01:28:49PM -0400, Chuck Zmudzinski wrote:
> On 9/16/22 1:03 PM, Russ Allbery wrote:

[...]

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

Fine example of trolling rhetorics, if there's one.

-- 
t

[toc] | [prev] | [next] | [standalone]

#12930 — Re: long-standing bugs and tar pits

On Fri, Sep 16, 2022 at 01:28:49PM -0400, Chuck Zmudzinski wrote:
>So Chuck Zmudzinski is on trial for hating Debian. What is
>the penalty?

I, for one, will personally de-prioritise anything I see your name
attached to; at least for a while.


-- 
Please do not CC me for listmail.

👱🏻	Jonathan Dowland
✎	 jmtd@debian.org
🔗	https://jmtd.net

[toc] | [prev] | [next] | [standalone]

#12931 — Re: long-standing bugs and tar pits (was: Are users of Debian software members of the Debian community?)

On Fri, Sep 16, 2022 at 10:57:16AM -0500, G. Branden Robinson wrote:
>As a person of gray Debian beard (but of sufficiently low profile to
>have been forgotten about as a developer)

You can't escape :P It's nice to see names that used to be a big part of
the "face" of Debian, such as yourself, pop up from time to time, so we
can know that you are still around. I hope life is treating you well.


-- 
Please do not CC me for listmail.

👱🏻	Jonathan Dowland
✎	 jmtd@debian.org
🔗	https://jmtd.net

[toc] | [prev] | [next] | [standalone]

#12920

[Multipart message — attachments visible in raw view] — view raw

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/20220629224938.7760-1-didi.debian@cknow.org/

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.

[toc] | [prev] | [next] | [standalone]

#12923

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#12928 — Re: How to make a positive impact by contributing

[Multipart message — attachments visible in raw view] — view raw

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-devel@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)

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.project

csiph-web