Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Why are some Debian bugs ignored for a long time?

17 views
Skip to first unread message

Chuck Zmudzinski

unread,
Aug 19, 2022, 2:00:06 PM8/19/22
to
Hello,

I have noticed that some Debian bugs are ignored for a long time, sometimes even when the person who submitted the bug offered a patch. The Debian developers/maintainers sometimes don't even reply and therefore never explain why the proposed patch cannot be applied. Why is that the case with Debian developers/maintainers?

Best regards,

Chuck

piorunz

unread,
Aug 19, 2022, 4:50:05 PM8/19/22
to
On 19/08/2022 18:57, Chuck Zmudzinski wrote:

> I have noticed that some Debian bugs are ignored for a long time, sometimes even when the person who submitted the bug offered a patch. The Debian developers/maintainers sometimes don't even reply and therefore never explain why the proposed patch cannot be applied. Why is that the case with Debian developers/maintainers?

Hi Chuck,

Maybe because developers/maintainers are not paid by the hour, but mere
volunteers, don't you think?

--
With kindest regards, Piotr.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀⠀⠀

Andy Smith

unread,
Aug 19, 2022, 7:00:06 PM8/19/22
to
Hello,

On Fri, Aug 19, 2022 at 05:06:38PM -0400, Chuck Zmudzinski wrote:
> On 8/19/2022 4:44 PM, piorunz wrote:
> > On 19/08/2022 18:57, Chuck Zmudzinski wrote:
> > > I have noticed that some Debian bugs are ignored for a long time, sometimes even when the person who submitted the bug offered a patch. The Debian developers/maintainers sometimes don't even reply and therefore never explain why the proposed patch cannot be applied. Why is that the case with Debian developers/maintainers?
> >
> > Hi Chuck,
> >
> > Maybe because developers/maintainers are not paid by the hour, but mere
> > volunteers, don't you think?
>
> So that means "free" software written and maintained by volunteers will never be as
> stable and secure as software that is written by people who are paid by the hour.

This is an assertion of your own that does not automatically follow
from what piorunz wrote.

> That is, Debian software can *never* be as stable and secure as
> software that is written and maintained by people who are paid by
> the hour.

This is also an assertion of your own that does not automatically
follow from what piorunz wrote.

> you are saying if a Debian user experiences a bug in Debian
> software, Debian developers/maintainers do not have to fix it.

That is a direct consequence of the meaning of the term "volunteer";
you may as well have said, "water is wet". Volunteers cannot be
forced to do work, else they are not volunteers.

> If Debian developers/maintainers actively refuse to fix some bugs that inevitably arise
> by ignoring them, why would anyone depend on Debian software for anything important?

I would argue that the situation is similar (and often worse) in
every other free software project.

I would also argue that while you may pay a software vendor to care
about your use case, that can also come with different issues.

So really, life is not perfect, and we all do what we can to cope
with that. Things are not perfect in Debian nor elsewhere both
within and outside the free software world.

I think I know some of the bugs that you are referring to as I keep
on eye on those developments. A gentle ping on the relevant bugs to
ask where things are may be appropriate. That's really the strongest
thing you can do. Others may be tempted to try to drag more info out
of you to determine what the exact history is here and who is
right/wrong, but I don't think that will help anyone in these
particular cases.

Regards,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

Chuck Zmudzinski

unread,
Aug 19, 2022, 8:30:05 PM8/19/22
to
On 8/19/2022 6:59 PM, Andy Smith wrote:
> Hello,
>
> On Fri, Aug 19, 2022 at 05:06:38PM -0400, Chuck Zmudzinski wrote:
> > On 8/19/2022 4:44 PM, piorunz wrote:
> > > On 19/08/2022 18:57, Chuck Zmudzinski wrote:
> > > > I have noticed that some Debian bugs are ignored for a long time, sometimes even when the person who submitted the bug offered a patch. The Debian developers/maintainers sometimes don't even reply and therefore never explain why the proposed patch cannot be applied. Why is that the case with Debian developers/maintainers?
> > >
> > > Hi Chuck,
> > >
> > > Maybe because developers/maintainers are not paid by the hour, but mere
> > > volunteers, don't you think?
> >
>
> > you are saying if a Debian user experiences a bug in Debian
> > software, Debian developers/maintainers do not have to fix it.
>
> That is a direct consequence of the meaning of the term "volunteer";
> you may as well have said, "water is wet". Volunteers cannot be
> forced to do work, else they are not volunteers.

The fact that Debian is created by volunteers and therefore the chances are
high that users might run into problems and not get help from the volunteers
who alone have the power to fix the problems is a fact that Debian users, and
all users of free software, need to keep in mind.

>
> > If Debian developers/maintainers actively refuse to fix some bugs that inevitably arise
> > by ignoring them, why would anyone depend on Debian software for anything important?
>
> I would argue that the situation is similar (and often worse) in
> every other free software project.

In Linux itself, I think it is *much* better than in Debian. I am going to try some other projects
and find out by experience where the consideration for the user has a higher priority than in
Debian.

>
> I would also argue that while you may pay a software vendor to care
> about your use case, that can also come with different issues.
>
> So really, life is not perfect, and we all do what we can to cope
> with that. Things are not perfect in Debian nor elsewhere both
> within and outside the free software world.
>
> I think I know some of the bugs that you are referring to as I keep
> on eye on those developments. A gentle ping on the relevant bugs to
> ask where things are may be appropriate.That's really the strongest
> thing you can do.

I do that and I am ignored. I am not holding my breath waiting for a response
from the relevant developers and maintainers. However, it would be a pleasant
surprise if they *did* respond and I would be grateful if they did. I just don't
think volunteers trying to help Debian but who ignore users who report bugs
in Debian is over the long term a good thing for Debian.

> Others may be tempted to try to drag more info out
> of you to determine what the exact history is here and who is
> right/wrong, but I don't think that will help anyone in these
> particular cases.

We agree on that point.

Best regards,

Chuck

Andy Smith

unread,
Aug 19, 2022, 9:20:04 PM8/19/22
to
Hi Chuck,

On Fri, Aug 19, 2022 at 08:20:21PM -0400, Chuck Zmudzinski wrote:
> On 8/19/2022 6:59 PM, Andy Smith wrote:
> > Volunteers cannot be forced to do work, else they are not
> > volunteers.
>
> The fact that Debian is created by volunteers and therefore the chances are
> high that users might run into problems and not get help from the volunteers
> who alone have the power to fix the problems is a fact that Debian users, and
> all users of free software, need to keep in mind.

A danger here is that you write as if this is a particular problem
for Debian, but I think you've merely stated a truism for every
volunteer effort of any kind.

People do sometimes need reminding that they are relying on a
volunteer effort, however.

> I am going to try some other projects and find out by experience
> where the consideration for the user has a higher priority than in
> Debian.

I am not going to tell you that Debian is the best Linux
distribution for you or anyone specific, though you could perhaps
expect responses along those lines given that we're having this
conversation in a Debian space.

The thing is though, you can experience a problem within one project
that is frustrating and demotivating and so move to another project
that does not have that particular problem, only to later experience
a different problem in the next project that is also frustrating and
demotivating. Only you can decide which one overall suits you best;
what's certain is that nothing is going to be perfect.

If any Linux distribution were asked, "do you consider the user
experience to be a high priority?" they are probably all going to
answer, "yes!" But in reality there will always be some decisions
(or lack of decisions) made where some number of users feel they
were mistreated.

If you have the time and interest to look at other distributions
it's probably not going to be wasted time, anyway, if only to
compare and contrast.

Cheers,

Joe Pfeiffer

unread,
Aug 19, 2022, 11:10:05 PM8/19/22
to
Chuck Zmudzinski <brch...@netscape.net> writes:

> On 8/19/2022 6:59 PM, Andy Smith wrote:
>> Hello,
>>
>> On Fri, Aug 19, 2022 at 05:06:38PM -0400, Chuck Zmudzinski wrote:
>> > On 8/19/2022 4:44 PM, piorunz wrote:
>> > > On 19/08/2022 18:57, Chuck Zmudzinski wrote:
>> > > > I have noticed that some Debian bugs are ignored for a long
>> > > > time, sometimes even when the person who submitted the bug
>> > > > offered a patch. The Debian developers/maintainers sometimes
>> > > > don't even reply and therefore never explain why the proposed
>> > > > patch cannot be applied. Why is that the case with Debian
>> > > > developers/maintainers?
>> > >
>> > > Hi Chuck,
>> > >
>> > > Maybe because developers/maintainers are not paid by the hour, but mere
>> > > volunteers, don't you think?
>> >
>>
>> > you are saying if a Debian user experiences a bug in Debian
>> > software, Debian developers/maintainers do not have to fix it.
>>
>> That is a direct consequence of the meaning of the term "volunteer";
>> you may as well have said, "water is wet". Volunteers cannot be
>> forced to do work, else they are not volunteers.
>
> The fact that Debian is created by volunteers and therefore the chances are
> high that users might run into problems and not get help from the volunteers
> who alone have the power to fix the problems is a fact that Debian users, and
> all users of free software, need to keep in mind.

This is equally true of commercial software: if the company feels it's a
low-enough impact bug it won't get fixed.

Commercial software has the additional risk that a product may simply
be withdrawn from the market. With cloud-based commercial software,
this means it could completely fail to function (one that's particularly
noticeable is that as companies withdraw from the home automation space,
consumers are discovering their smart home has suddenly become
completely dumb).

to...@tuxteam.de

unread,
Aug 20, 2022, 1:30:05 AM8/20/22
to
On Fri, Aug 19, 2022 at 05:06:38PM -0400, Chuck Zmudzinski wrote:
> On 8/19/2022 4:44 PM, piorunz wrote:
> > On 19/08/2022 18:57, Chuck Zmudzinski wrote:
> >
> > > I have noticed that some Debian bugs are ignored for a long time [...]
> >
> > Hi Chuck,
> >
> > Maybe because developers/maintainers are not paid by the hour, but mere
> > volunteers, don't you think?

There is another point: the package maintainer is very autonomous
in how (s)he does her thing. This has advantages and disadvantages.

There are processes in place for resolving such situations as when
a maintainer becomes unresponsive (perhaps (s)he has moved on to
other things, perhaps (s)he is in some situation of distress). Among
others, there is the NMU [0].

This question comes up regularly in this list. Had you searched
the archives, you'd found things like this [1] with advice (hint:
this would leave developers more time for fixing bugs ;-)

There is good advice by Jonathan Dowland in the linked thread on
how to do something about it. Want to give it a try?

> So that means "free" software written and maintained by volunteers will never be as
> stable and secure as software that is written by people who are paid by the hour.

This is, of course, nonsense. This would be only the case if
the instance giving out the cash had an interest on the software
being "stable and secure". Most of the time they have an interest
on the software being sold, or on it generating cash flow via
other means (gathering user data, for that to be sold, for example).

So they will allocate their resources accordingly. I've worked
in the belly of big corps for a while and I assure you that my
boss wouldn't allow me to fix a bug unless (s)he could justify
to their bosses that the 1400 dollars "spent" on this are coming
back in some way.

Witness the whole history of Microsoft software with its incredible
ecosystem of malware, and you'll see how wrong your idea is :)

So each "world" has its upsides and (surprise!) its downsides.

That doesn't mean I wouldn't like to see projects like Debian
better funded, mind you. There are also people thinking about
this. There are companies which sponsor Debian, there are
companies which let employees work for Debian on their company
time; one seemingly successful example is Freexian [2], which
offers services by keeping alive older versions of Debian.

I get you want to contribute?

;-)

Cheers

[0] https://wiki.debian.org/NonMaintainerUpload
[1] https://lists.debian.org/debian-user/2022/05/threads.html#00028
[2] https://www.freexian.com/services/debian-lts.html

--
t
signature.asc

Teemu Likonen

unread,
Aug 20, 2022, 3:50:06 AM8/20/22
to
* 2022-08-19 17:06:38-0400, Chuck Zmudzinski wrote:

> On 8/19/2022 4:44 PM, piorunz wrote:

>> Maybe because developers/maintainers are not paid by the hour, but
>> mere volunteers, don't you think?
>
> So that means "free" software written and maintained by volunteers
> will never be as stable and secure as software that is written by
> people who are paid by the hour. That is, Debian software can *never*
> be as stable and secure as software that is written and maintained by
> people who are paid by the hour.

Too much generalizing. If some piece of software has bugs and no active
maintenance then that particular software may be insecure, but not the
whole software category (by maintenance strategy).

Almost every piece of software is maintained different way and has its
own security concerns. There is no general security rule for all
volunteer maintained and all paid-by-hour maintained software. Both
volunteers and companies lose interest in maintaining software at some
point. I don't know which strategy is generally better, but even if I
knew, the knowledge wouldn't say anything about any particular piece of
software.

It's good to bring attention to long-ignored bugs in Debian. It can help
get them fixed sooner.

--
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462
signature.asc

piorunz

unread,
Aug 20, 2022, 6:20:06 AM8/20/22
to
On 19/08/2022 22:06, Chuck Zmudzinski wrote:

> So that means "free" software written and maintained by volunteers will never be as
> stable and secure as software that is written by people who are paid by the hour. That is,
> Debian software can *never* be as stable and secure as software that is written and
> maintained by people who are paid by the hour.

Oh, that means Microsoft Windows must be most stable OS in the world,
right?
Right?...

> Not only that, you are saying if a Debian
> user experiences a bug in Debian software, Debian developers/maintainers do not have
> to fix it. That's fine, but...
>
> If Debian developers/maintainers actively refuse to fix some bugs that inevitably arise
> by ignoring them, why would anyone depend on Debian software for anything important?

Did you not read Debian disclaimer when you log in?

"The programs included with the Debian GNU/Linux system are free
software; the exact distribution terms for each program are described in
the individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law."

You are free to use paid software if you think it is somewhat better. In
line with your logic, I think Microsoft Windows is an excellent choice
for you.

Brian

unread,
Aug 20, 2022, 8:30:05 AM8/20/22
to
AFAICT, there isn't any requirement for a maintainer/triager to engage
with each and every submitted bug report.

https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#bug-handling

Each report is unique and so is every maintainer. Therefore it is not
possible to generalise with certainty on the reasons for not getting an
immediate response.

Neither should a user have any expectation of a timely interaction, nice
though it may be to be get further involvement from a maintainer.
Reasons for the perceived "ignored" status might be:

* The maintainer judges that the bug affects very few users.
* The maintainer does not have the resources to deal with the bug.
* A solution is already in hand and awaiting upload to unstable.
* The maintainer puts the report on the back burner and forgets about
it.
* The bug is low down on the priority list.
* The maintainer sees the bug as a user issue and not an issue with
package quality.
* The maintainer has little or nothing to contribute that would lead to
the report progressing.
* Fixing this issue is not worth the effort, if possible at all.

--
Brian.

Brian

unread,
Aug 20, 2022, 10:30:05 AM8/20/22
to
On Sat 20 Aug 2022 at 09:06:54 -0400, Chuck Zmudzinski wrote:

> On 8/20/2022 1:25 AM, to...@tuxteam.de wrote:

[...]

> > I get you want to contribute?
>
> Yes, that's what mystifies me. I don't know why Debian ignores
> someone who wants to contribute time to help the project.
>
> In another case, the bug was upstream and although I reported the
> bug on Debian first, marked it 'patch' and 'upstream' in the BTS, it was
> still being ignored, so I just submitted the patch directly to upstream who
> accepted my patch.

You did the best possible thing.

> Usually upstream projects want and expect users to report bugs to
> the distro, not to the upstream project, for many good reasons that I
> need not explain here.

You would have to explain it for my benefit because I am not familiar
with that procedure.

> Then the distro package maintainer, rather
> than the user, interacts with the upstream developers and maintainers.

That is the general practice, but it is not unknown for the maintainer
to request the user to forward the report upstream.

> Of course if the distro maintainers ignore upstream bugs reported to the
> distro, the whole free software ecosystem will suffer, not just Debian.

Fair comment.

--
Brian.

Greg Wooledge

unread,
Aug 20, 2022, 10:50:05 AM8/20/22
to
On Sat, Aug 20, 2022 at 03:22:27PM +0100, Brian wrote:
> On Sat 20 Aug 2022 at 09:06:54 -0400, Chuck Zmudzinski wrote:
> > Usually upstream projects want and expect users to report bugs to
> > the distro, not to the upstream project, for many good reasons that I
> > need not explain here.
>
> You would have to explain it for my benefit because I am not familiar
> with that procedure.

When encountering a bug in a Debian package, the typical end user has
no way of knowing whether the bug is in the upstream program, or in the
patches added by Debian.

So, the correct thing for the end user to do is to report the bug to
Debian's bug tracking system. If the maintainer determines that the
bug is in the upstream code, then the maintainer is supposed to pass
the bug upstream.

Of course, this assumes limited knowledge on the part of the end user,
and active maintenance by the Debian maintainer. Either of those things
might turn out not to be the case.

An end user with a bit of technical prowess might build the upstream code
and test it to see whether the bug is also there.

A Debian maintainer might turn out to be severely inactive, for any
number of reasons.

In the end, everyone just has to do the best they can with the knowledge
they possess.

to...@tuxteam.de

unread,
Aug 20, 2022, 11:30:06 AM8/20/22
to
On Sat, Aug 20, 2022 at 11:14:27AM -0400, Chuck Zmudzinski wrote:

[...]

> > So they will allocate their resources accordingly. I've worked
> > in the belly of big corps for a while and I assure you that my
> > boss wouldn't allow me to fix a bug unless (s)he could justify
> > to their bosses that the 1400 dollars "spent" on this are coming
> > back in some way.
>
> There are plenty of "volunteers" for free software projects that also
> work, as you say, in the "belly of big corps." Are you suggesting these
> "volunteers" will ignore bugs in free software projects because their
> boss does not want them to fix the bugs in the free project and force
> users to buy a paid version of the project?

No. I'm not talking about what those people do /as volunteers/ (i.e.
in their free time, out of their own motivation), but /as employees/
(i.e. on "company time"). This was in answer to your

> > So that means "free" software written and maintained by volunteers will never be as
> > stable and secure as software that is written by people who are paid by the hour.

It should be clear that the same person may play different roles (e.g.
"paid by the hour" or "free time").

When paid by the hour, it is clear that the employer has a say in what
the employee uses her time for. If the bug doesn't seem important to
the company, it won't get fixed.

Cheers
--
t
signature.asc

Brian

unread,
Aug 20, 2022, 12:10:05 PM8/20/22
to
On Sat 20 Aug 2022 at 16:13:29 +0100, Brad Rogers wrote:

> On Sat, 20 Aug 2022 15:22:27 +0100
> Brian <ad...@cityscape.co.uk> wrote:
>
> Hello Brian,
>
> >On Sat 20 Aug 2022 at 09:06:54 -0400, Chuck Zmudzinski wrote:
> >> On 8/20/2022 1:25 AM, to...@tuxteam.de wrote:
>
> >> Usually upstream projects want and expect users to report bugs to
> >> the distro, not to the upstream project, for many good reasons that I
> >> need not explain here.
> >
> >You would have to explain it for my benefit because I am not familiar
> >with that procedure.
>
> Distros can, and do, apply patches to software. Bugs should be reported
> to distros in the first instance because the maintainers are best placed
> to determine if the bug is specific to the distro or not. Furthermore,
> the bug reported may not even be in the package it was reported against,
> but in (say) a library that the package uses. Either way, the package
> maintainers can pass the bug to the relevant place (self, other package
> within distro, upstream).
>
> If we all went straight to the dev team of the software, they would end
> up having to deal with a load of distro specific stuff they have no hope
> of fixing. Of course, that's be a massive waste of everybody's time.
>
> Plus, of course, what Greg said.

What you and Greg Wooledge say makes complete sense. I suppose it
also helps our users by exposing the bug in the BTS and, theoretically,
avoids duplication of reports. It was just that my limited experience
does not include upstreams wanting and expecting bugs to be reported
first to the distro as a matter of course, sensible though it might be.
As has been said:

> In the end, everyone just has to do the best they can with
> the knowledge they possess.

I would expect that "everyone" includes maintainers.

--
Brian.

Stefan Monnier

unread,
Aug 20, 2022, 2:10:06 PM8/20/22
to
> So that means "free" software written and maintained by volunteers will never be as
> stable and secure as software that is written by people who are paid by the hour.

Not necessarily. Have you filed a bug report about a problem you
perceived in macOS, Windows, other your usual shrink wrapped software?
Has it always been fixed promptly?

If you want your bugs to be fixed, you generally need resort to some
kind of support contract, which you can get for Free Software just as
easily as for proprietary software (probably more easily, actually).

Notice also that the goal of Free Software is not to be technically
better (you may be confusing it for Open Source software), but
ethically better.

I suspect most maintainers who don't respond promptly to bug reports
aren't happy about that fact: its demoralizing to be in charge of
something you can't devote the resources it really deserves.

But note that *you* can help, by taking on some of the work, looking for
bugs that haven't gotten an answer yet and trying to address them.
I don't think anyone can do that for any random bug, but I'm pretty sure
most people on this list would be able to do that for at least one of
the pending bug reports.


Stefan

Stefan Monnier

unread,
Aug 20, 2022, 4:30:05 PM8/20/22
to
Chuck Zmudzinski [2022-08-20 16:20:21] wrote:
> That's a fair point. It may not be so easy for me to work on a bug that does not affect
> my systems, but I am willing to help with bugs important to the Debian project now, as
> the bookworm development process continues. I will take some time and see if I can
> help out with some other open bugs that do not directly affect my systems. Such bugs
> can be found by querying BTS for bugs marked as critical or grave by the maintainer
> and bugs that are blocking a release, as these are the ones most important to the
> maintainers and developers. I don't know if I have the skills to fix such bugs which are
> probably not so easy to fix, but it wouldn't hurt to ask if there is anything I can do to
> help. One thing that is always helpful are testers to test the proposed fixes for open
> bugs, and I could help with that in cases when the bug affects a package on one or more
> of my systems, at least to tell the maintainer, "that proposed fix looks good, it does not
> break anything on my systems."

Yes, there are many things one can do to help. E.g. several bugs are
misfiled (for example, sent to the Debian maintainer instead of being
sent to the package's developer even though the bug is unrelated to the
Debian packaging itself). Or often the bug report lacks information to
reproduce it.


Stefan

to...@tuxteam.de

unread,
Aug 21, 2022, 1:20:06 AM8/21/22
to
On Sat, Aug 20, 2022 at 04:20:21PM -0400, Chuck Zmudzinski wrote:
> On 8/20/2022 2:06 PM, Stefan Monnier wrote:

[...]

> > But note that *you* can help, by taking on some of the work, looking for
> > bugs that haven't gotten an answer yet and trying to address them.
>
> That's a fair point. It may not be so easy for me to work on a bug that does not affect
> my systems, but I am willing to help with bugs important to the Debian project now, as
> the bookworm development process continues [...]

Yay! Thank you!

Cheers
--
t
signature.asc

Oliver Schoede

unread,
Aug 21, 2022, 4:10:05 AM8/21/22
to
On Sat, 20 Aug 2022 13:26:14 +0100
Brian <ad...@cityscape.co.uk> wrote:

>Reasons for the perceived "ignored" status might be:
>
> * The maintainer judges that the bug affects very few users.
> * The maintainer does not have the resources to deal with the bug.
> * A solution is already in hand and awaiting upload to unstable.
> * The maintainer puts the report on the back burner and forgets about
> it.
> * The bug is low down on the priority list.
> * The maintainer sees the bug as a user issue and not an issue with
> package quality.
> * The maintainer has little or nothing to contribute that would lead
> to the report progressing.
> * Fixing this issue is not worth the effort, if possible at all.
>

No, these are (more or less reasonable) grounds for not getting *to
work* on some potential issue, and that is what you state yourself! With
one exception--a fix warranting no further comment is imminent--none of
these points however justifies providing no *feedback* to begin with,
and if it's a won't-fix/don't care plus signature. In fact, most if not
all would seem to explicitly ask for it. I'd even think there might
well be less reason for interaction other than the auto confirmation
once some change is pending, especially if it's obvious. As I
understand it though Chuck is not primarily complaining about ignored
issues. But about ignored reporters. We are a peoples project?

And while I perfectly understand there can be countless causes
*even* preventing maintainers from providing feedback, whether timely or
long-time, this is simply an entirely different matter and would have to
be explained in another way. At least this is getting us somewhere:

>
>Neither should a user have any expectation of a timely interaction,
>nice though it may be to be get further involvement from a maintainer.

So be it. If also a rule I'm afraid it's probably about as old as
Debian and a rather antiquated conception of software development or
the expectations of its wider ecosystem. Nor does volunteering in itself
relieve you from certain minimal considerations that naturally arise
when contributing to what is ultimately a social enterprise.
Not to mention that, hopefully, all testing and bug reporting here is
just as voluntary. ;) It's the whole point, isn't it? And if
consideration means to, perhaps temporarily, *visibly* suspend some
role when there's not enough time or more pressing issues, or at least
to leave some clue to that effect somewhere, like on a personal
website, as some have done. Pushing issues into some black hole however
isn't exactly enticing, I can easily imagine technically advanced users
instead rather sorting some things out themselves immediately, locally,
and from experience just forgo the BTS altogether.


Oliver

to...@tuxteam.de

unread,
Aug 21, 2022, 4:30:05 AM8/21/22
to
On Sun, Aug 21, 2022 at 10:06:08AM +0200, Oliver Schoede wrote:
> On Sat, 20 Aug 2022 13:26:14 +0100
> Brian <ad...@cityscape.co.uk> wrote:
>
> >Reasons for the perceived "ignored" status might be:
[...]

> No, these are (more or less reasonable) grounds for not getting *to
> work* on some potential issue, and that is what you state yourself! With
> one exception--a fix warranting no further comment is imminent--none of
> these points however justifies providing no *feedback* to begin with,
[...]

That's how *you* think things should be. If you don't put any effort
into making it happen, this mail stays what it is: a useless rant.

Telling others what they should do will be pretty ineffective unless
you have something to offer in exchange :-)

Cheers
--
t
signature.asc
0 new messages