Re: Planned changes for to reduce the "Bugzilla blues"

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


On Sun, Oct 02, 2022 at 09:07:13PM +0000, Artem S. Tashkinov wrote:
> > > Why are people are now blowing stuff out of proportion for no reason?
> > 
> > Because the approach is wrong. As I explained it gives a false sense to
> > the reporter that their issue is being handled while the simple fact that
> > a message was sent to a person is in no way an engagement to do anything
> > about it. LKML is a broadcast area. Everyone hopes someone else will
> > respond and that eventually happens. When the reports are targetted, it
> No, it doesn't happen. Should I open LKML and send you a hundred of
> unreplied emails over the past year alone?

If that makes you feel better, feel free to do so. I'm not scared by
only one hundred e-mails. What I'm impressed by, however, is that you're
able to spot that many unreplied e-mails because I don't see as many. If
you're that efficient at spotting them, maybe these are the ones you
should just resend to make sure they're seen, and it would require less
work (even on your side) than triaging issues.

> Just before I GTFO I will leave this bug report here (already posted it
> here but maybe I need to do it again and again):
> Tell me honestly how ~255 comments, and a ton of collaboration over the
> span of 2.5 years can be managed using email.

What makes you think it would have taken that long over e-mail ? Between
your first report and the first reply "this is not a bug", 18 months had
elapsed already. The most active part of the discussion happened grouped
on 3 days (2021-03-19 -> 22), where there were already some "I'm removing
myself from the CC because the discussion isn't productive", then a large
number of "me too" happened. Not sure how much useful this has been
overall to the involved developers, given that it's impossible to stay
focused on that long a thread and sum up all the information spanning
over that many kernel versions and that many different hardware.

My gut feeling is that handling this over the ML would have resulted in:
  - a few "sorry, no solution, try to fix your BIOS"
  - "try this" => "it works, thank you".
  - "this fix above broke for me"
  - and a few such iterations until a satisfying enough solution would
    have been found. Maybe not in 2.5 years, maybe 6 months.

But I could be wrong. I'm not claiming I know how people feel the most
efficient. Just observing what we're seeing on the lists and what I'm
used to dealing with in some bug trackers. If you want I can as well
show you a bug I reported 19 years ago that's still in state "NEW",
having seen little updates over the years. It had better been closed
since then, TBH:

Pretty close to your demo above except it lasted 8 times longer and
has not seen progress by lack of interest. How's that different from
what you complain about mailing lists ? Hmm ?


[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux