Message-ID: <877doht7bd.fsf@intel.com>
Date:   Wed, 13 Jan 2021 13:17:10 +0200
From:   Jani Nikula <jani.nikula@...ux.intel.com>
To:     Thorsten Leemhuis <linux@...mhuis.info>,
        Jonathan Corbet <corbet@....net>,
        Randy Dunlap <rdunlap@...radead.org>,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 (RFC)] docs: discourage users from using bugzilla.kernel.org

On Tue, 12 Jan 2021, Thorsten Leemhuis <linux@...mhuis.info> wrote:
> Thx for your reply and sorry for forgetting to CC you; that was the
> plan, but I forgot when I called git send-email :-/
>
> Am 11.01.21 um 20:48 wrote Konstantin Ryabitsev:
>> On Sun, Jan 10, 2021 at 01:10:33PM +0100, Thorsten Leemhuis wrote:
>>> The front page doesn't make this aspect obvious and not even point to
>>> Documentation/admin-guide/reporting-bugs.rst to help those that want to
>>> properly report a bug. Only the FAQ mentions it, albeit only indirectly:
>>> 'The subsystem maintainers in kernel tracker are volunteers to help
>>> track bugs in an area they are interested in. Sometimes they are the
>>> same person as on kernel.org sometimes they are not. There are still
>>> some categories with no maintainers so more volunteers are needed.'
>> My general comment on this is that bug triage sucks and nobody really wants to
>> do it for any extended period of time. :) There were times in the past when
>> this or that person did step up and kept an eye on all incoming new bugs,
>> properly routing them to the proper product/component, but they quickly burned
>> out or found a less thankless occupation. Understandably.
>
> Yeah, I can relate to that, too.
>
>>> It looks like those volunteers were never found; the outdated list of
>>> components and products (see 'the bad' above) also shows that the
>>> volunteers seem to not really take care of things.
>> I want to encourage you and the rest of the developers to complain about this
>> to the TAB. It is entirely in their power to come to the Linux Foundation with
>> the suggestion that perhaps bug triage should be a paid position. It's not a
>> given that such a position would then be created and funded, but this for sure
>> won't happen if these complaints don't reach People In Charge Of Funds at the
>> LF.
>
> Hmmm, I'll have to think about that. I'm not sure yet if I'm currently
> willing to enter enter such a fight^w^w^w^w go down that route – I soon
> have other things on my plate and not much time to spare for this. Sure,
> bringing this to TAB is not that much work, but I expect that will lead
> to a longer process that will involve lots of arguments that will need
> to get exchanged by mail... And I don't care that much about bugzilla,
> that why I spend time wring the recently added text
> Documentation/admin-guide/reporting-issues.rst
>
>
>
>>> In the end that's the reasons why quite a few (a lot?) reports never get
>>> a reply from someone. During a randomly selected 2 week window at the
>>> end of November 2020(¹) there were 60 public bugs and a bit more than
>>> half of them by the end of the year never got a single comment by anyone
>>> except maybe the reporter.
>> Well, that said, a lot of stuff sent to the _proper_ mailing lists also never
>> receives a response
>
> Good point.

There's a school of thought that this is actually a feature. If there's
no attention, the reports on the list will just fade away and be
forgotten. Whereas in bugzilla, someone needs to actively resolve even
the ignored and forgotten bugs. (Or it needs to be automated.)

Attending to a bug database of thousands of open bugs takes a huge
amount of effort, and if the bugs aren't being fixed, a lot of that
effort is just wasted. If a bug doesn't get fixed now (or soon-ish),
what are the chances it'll get fixed months or years down the line?

---

Just musing, has anyone else seen a shift in bug reports from "I'm part
of the community, and I want to help improve this stuff" towards "I'm a
customer and I demand support"? I don't think the kernel community can
really cater to the latter very well, and would be better directed at
distro bug trackers.

BR,
Jani.




>
>> -- either because it didn't catch appropriate eyeballs or
>> because those eyeballs didn't have time to spend on the required
>> back-and-forth to identify the source of the problem.
>
> Or because the bug report was obviously so bad no one dared to touch it.
> But that reason and the two you mentioned are all covered in
> Documentation/admin-guide/reporting-issues.rst
>
> Sure, not everybody will read that far, but at least those that do will
> find help. And yes, the text could cover those situations for
> bugzilla.kernel.org as well, but that afaics would boil down to 'report
> to the place that is mentioned in the MAINTAINERS file (as you better
> would have right from the start)'.
>
>> I don't think we should
>> be using this metric as indication that bugzilla doesn't work.
>
> Well, FWIW, that's why I described it as 'doesn't work that well' and
> had a 'the good' section in my patch description, as it clearly is
> useful sometimes. That's also why I'm not on a quest 'kill bugzilla with
> fire'. ;-)
>
> Nevertheless I think discouraging users from filing bugs there is a good
> way to quickly improve the situation, as chances a good bug report will
> be acted upon afaics are currently much better when they get reported to
> the proper place: the one mentioned in the MAINTAINERS file.
>
>>> But there is one aspect that should be noted here: The situation can't
>>> be blamed on the kernel.org admins. They are doing a good job at keeping
>>> the bugzilla.kernel.org up and the bugzilla codebase up2date. But as
>>> admins it's not their job to maintain the list of products and
>>> components.
>> Aw, thanks. :) It's indeed hard enough just keeping all the spam off it.
>> Unfortunately, there are no perfect solutions for it, but usually all spam is
>> junked and hidden from public view within an hour or two of being posted.
>> Sadly, this usually happens after spammy notifications have already gone out.
>
> Ouch. Maybe that's one good reason to make bugzilla.kernel.org either
> work properly or kill it, to make sure the time your spent on things
> like this is actually worth it.
>
>>> Apart from this change there is one more change planned to improve the
>>> situation with bugzilla.kernel.org: discuss with the admins how to make
>>> it more obvious to users when to use the bug tracker, and when to avoid
>>> it; the text that does this will obviously link to
>>> Documentation/admin-guide/reporting-issues.rst, which is one of the
>>> reasons why it's designed to be understandable for newcomers.
>> I'm not sure there's any single solution that will solve the problem. If we
>> properly organize products/components, many people will just get lost in them
>> and create all bug reports in "other" (or "helpdesk", as is the case lately).
>
> Yeah, the kernel is complex and might benefit from a 1st level support
> that relays good reports to the appropriate developers or maintains. But
> such a solution would need time and money to set up. Until something is
> happening in that direction I'd say a patch like mine is a good idea and
> can easily get reverted later if the situation with bugzilla.kernel.org
> improves.
>
>> The sanest approach would be to have a simple web gateway to bug reporting:
>
> +1
>
>> - which distribution are you using?
>> - if they choose a distribution, show them where to report bugs for that
>>   distribution, because most bugs should start there, really
>
> Agreed. Fun fact: that why the step-by-step guide in
> Documentation/admin-guide/reporting-issues.rst starts with "Stop reading
> this document and report the problem to your vendor instead, unless you
> are running the latest mainline kernel already or are willing to install
> it. " ;-)
>
>> - on that page, also give a link:
>>   "I'm a distribution maintainer and I want to report this bug upstream"
>> - if they click that link, let them fill out a freeform bug report that will
>>   create a new bug entry on bugzilla.kernel.org in "Other/Other"
>> - creating a bug there will email the designated person in charge of initial
>>   bug triage
>> - that designated person or persons will then assign proper product/component,
>>   or simply forward the bug report to the proper maintainer if they are able
>>   to ascertain that
>
>
> Well, do we really need bugzilla and a middleperson for triaging and
> forwarding when it we are taking about reports filed by distribution
> maintainers? They are unlikely to be newcomers to FLOSS bug reporting,
> so they IMHO should be able to read the MAINTAINERS file and follow
> Documentation/admin-guide/reporting-issues.rst
>
>> This is far from perfect and still hinges on finding a person willing to do
>
>> bug triage. However, it should hopefully improve the workflow without making
>
>> it too complicated.
>
> It might imrpove the workflow, but one question wasn't raised: why do we
> need two places to report bugs to at all? The MAINTAINERS file is there
> and the places specified there are clearly the ones maintainers prefer.
> Sure, bugzilla is easier to handle, especially for for inexperienced
> users. But is that worth it? Especially in its current state?
>
> Ciao, Thorsten

-- 
Jani Nikula, Intel Open Source Graphics Center

Powered by blists - more mailing lists