Message-ID: <867b35b7-da2b-fed0-1f75-b2021d9be499@gmx.com>
Date:   Sun, 2 Oct 2022 21:53:58 +0000
From:   "Artem S. Tashkinov" <aros@....com>
To:     Willy Tarreau <w@....eu>
Cc:     Konstantin Ryabitsev <konstantin@...uxfoundation.org>,
        Theodore Ts'o <tytso@....edu>,
        Thorsten Leemhuis <linux@...mhuis.info>,
        Greg KH <gregkh@...uxfoundation.org>,
        workflows@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        "regressions@...ts.linux.dev" <regressions@...ts.linux.dev>,
        ksummit@...ts.linux.dev,
        Mario Limonciello <mario.limonciello@....com>
Subject: Re: Planned changes for bugzilla.kernel.org to reduce the "Bugzilla
 blues"



On 10/2/22 21:32, Willy Tarreau wrote:
> 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.

So, we've been worked up about a _possible_ SPAM issue and your response
is ... create more SPAM? How does it solve all the other issues with
email I've identified?

>
>> 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):
>>
>> https://bugzilla.kernel.org/show_bug.cgi?id=204807
>>
>> 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.

It's easy to join an existing bug report. Tell me how can I join an
existing email thread without being first subscribed to it? I certainly
can, absolute most people will not be able to.

What about sending large dump files? Should everyone on the mailing list
receive it?

A bug report is a simple plain list of messages in a single place which
could be read with a web browser. An email thread is anything but.

Searching through many emails at once? Good luck with that.

Replying to a particular email? Good luck with that.

It looks like you're under the impression that every Linux user who is
willing to ever use Linux must:

1) Subscribe to _all_ the existing mailing lists (just in case - what if
you need to work on something which was started by someone else)
2) Know the email etiquette
3) Learn to be persistent and resend (an unknown number of times) your
concerns hoping they will eventually be addressed.

Bugzilla: sign up once. Follow up. If you file a dupe, hopefully it will
be marked as a dupe. Everyone's happy. No particular skills, email
clients, formatting, referencing, etc. etc. etc.

All the developers busy and no one wants to work on your bug report?
That's Linux, you've got it for free. Submit a patch or pay someone
who'll fix your issue.

Regards,
Artem

>
> 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:
>
>     https://gcc.gnu.org/bugzilla/show_bug.cgi?format=multiple&id=11873
>
> 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 ?
>
> Willy

Powered by blists - more mailing lists