Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp914243pxb; Fri, 22 Apr 2022 14:10:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw5bj2mJ9+QrA64BRku7T53ipr+x+etKckLKnLOreMneFM4v8pWph0qymnNNl/nI7bZjoqF X-Received: by 2002:a17:90b:1e4d:b0:1d2:a7dc:63c7 with SMTP id pi13-20020a17090b1e4d00b001d2a7dc63c7mr18487193pjb.140.1650661833356; Fri, 22 Apr 2022 14:10:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650661833; cv=none; d=google.com; s=arc-20160816; b=R5jrKpeSzJKZDsL0rF1UaWyjqr9F8FGEmx7Gww/5B+L+cUnjn+TzDn3/Iw8pkn6eHl pTzOvMQKXM/PTC6Xa+BLdiHJYHquBO9IFYjyTf6hcmjibyceq6RzFyfJ4oXhHF9jkUpL edYUuIJjDqX8ouKodEoQuuR7TbBCW6ya276o/742bX/RG3/EKFPrhrxBjzsWmVbRjdVk BO986rMJ9ooS0SfeOvxGpwwjMihJoODgvO9+jsAbP4g95/vEWrVw2cZonU10PiN1X5P1 Xr0u5FLLHrHk4Rjt7gQ7Kt1u50EyPapr3NxoFzjWeoUbsHz9SuampApPTu8hXtUW75XN W16A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:subject :from:references:cc:to:content-language:user-agent:mime-version:date :message-id; bh=HzYHhJCK+PqBmbaAyIqwR+hkkkbkBL9R1hDBYd6szI0=; b=lbDaBwyHJKvKnd26Cpd4GEsmPK1cDr7QwD27vX1nRrr23xDZSF5oK2fxOfTRgiWLVI WNbkUWzc3MCxOvXL3kjhJLiN0cQc+DmlRrXDLz/nfMNJAWTDkfLO2paxwBbFHKSpotpR xphxX+gKJH2EBPruIko8vjtTx2GOAEW9Hyx2QxNvCt5GHDM7BnF3wO0P3IVt0pfrQDAC 3sH+Q/A6XXs37Bbm+CnGD3BPghPnLdAVx6P2fEttUzNxejXWSLBq2cbHl8JgN1ZP/WJ7 wvSiVSpTji6CMm6Dq0Ta80wysoC7d9fbhHEiMKJ3Utsp3vv8DZYNVeWz/dwmNDtUyrsH tHcA== ARC-Authentication-Results: i=1; mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id l12-20020a170902f68c00b0015605a57d10si9579467plg.523.2022.04.22.14.10.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Apr 2022 14:10:33 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 78453379533; Fri, 22 Apr 2022 13:09:55 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1378331AbiDTMAF (ORCPT + 99 others); Wed, 20 Apr 2022 08:00:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37470 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244583AbiDTMAC (ORCPT ); Wed, 20 Apr 2022 08:00:02 -0400 Received: from wp530.webpack.hosteurope.de (wp530.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8234::]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E79721CFC9; Wed, 20 Apr 2022 04:57:15 -0700 (PDT) Received: from [2a02:8108:963f:de38:6624:6d8d:f790:d5c]; authenticated by wp530.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1nh8xN-0007Pq-Am; Wed, 20 Apr 2022 13:57:13 +0200 Message-ID: <20ad7c63-c837-6f6e-6bbe-7b49d653e033@leemhuis.info> Date: Wed, 20 Apr 2022 13:57:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Content-Language: en-US To: Krzysztof Kozlowski , Linus Torvalds , Greg KH , Konstantin Ryabitsev Cc: "regressions@lists.linux.dev" , Linux Kernel Mailing List , workflows@vger.kernel.org References: <6808cd17-b48c-657d-de60-ef9d8bfa151e@leemhuis.info> From: Thorsten Leemhuis Subject: Re: A lot of regression reports submitted to bugzilla.kernel.org are apparently ignored, even bisected ones In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-bounce-key: webpack.hosteurope.de;linux@leemhuis.info;1650455836;2df81ad0; X-HE-SMSGID: 1nh8xN-0007Pq-Am X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, RDNS_NONE,SPF_HELO_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 20.04.22 12:31, Krzysztof Kozlowski wrote: > On 06/04/2022 14:35, Thorsten Leemhuis wrote: >> Hi! TLDR: I looked closer at every ticket filed in bugzilla.kernel.org >> over a time span of two weeks to see how well reports are handled, in >> particular those for kernel regressions. The results of this rough >> analysis are kinda devastating from my point of view. I for example >> found 8 tickets describing a regression where the reporter had even >> bisected the problem, but nevertheless the ticket afaics didn’t get a >> single reply or any other reaction from a regular kernel developer >> within about a week; in fact out of a total of 20 reports that looked >> like regressions to me (17 if you exclude tickets where the reporter >> used an afaics lightly patched distro kernel), only one got a helpful >> reply from a developer within a week. > To respond, developer would first had to be notified. Did it happen? Or > just some default assignee got automated notification? I didn't check, as I didn't care about the individual developers performance for this analysis: I just wanted to check how good or bad bugzilla is working for the Linux kernel development community as a whole. My expectations were low already, but the numbers I came up with were even worse than expected. >> That makes us miss valuable >> reports and puts our "no regressions" rule into a bad light. Hence, >> something IMHO should be done here to improve the situation, but I'm not >> sure myself what exactly -- that's why I'm writing this mail. A better >> warning on bugzilla’s frontpage suggesting to report issues by mail >> maybe? And/or disable all bugzilla products and components where it's >> not clear that somebody will be looking at least once at submitted tickets? > > I find such Bugzilla useless - the Components are not matching reality, > Products look ok except missing really a lot. Does it have proper > assigners based on maintainers? Nope. At least not everywhere. > > All the bug or issue reports I get via email and I think I am not alone > in this. All automated tools (kbuild, kernelCI) are using emails for bug > reporting. Why having one more system which seems not up to date? I'm the wrong one to ask, as I think it's a disservice right now that needs to be dealt with -- for example by turning it off or by making it work properly. But to my knowledge there is nobody really responsible for it (apart from Konstantin and his team, but they are afaics only responsible for running bugzilla the software -- not for maintaining components, products, and such things). That's afaics why we as the kernel developers community need to come up with a decision. But maybe mailing lists are a bad tool for this and this needs to wait till kernel and/or maintainers summit in September (it's already on the list of topics I plan to propose). > The only reliable and up to date information we have in maintainers > file: who is responsible and whom to CC (e.g. lists). That's why the current "reporting issues" document (which is even linked prominently on the front-page of bugzilla.kernel.org and mostly written by yours truely) tells everyone to look there and even discourages using bugzilla.kernel, unless the MAINTAINERS file mentions it as official point of contact (the last time I checked that was the case for roundabout 20 entries, mainly ACPI, PM, and PCI). But most people simply don't read the docs and just use the bug-tracker; seems that's just how humans are. :-D > I can give example from my domain: > https://bugzilla.kernel.org/show_bug.cgi?id=210047 > > This is clearly issue for me but there is no way I was notified about > this. I just found it by using the keyword from maintainers. Wrong > mailing list as Assignee, no CC to me. Such bug reports will be missed > because there is no way I can receive information about them. Why then > providing interface for bug reports which by design will not reach the > respective person? I have no idea, but to play devils advocate for a moment: it didn't happen by design, things like that just happened in loosely organized projects -- and for many years now nobody simply cared enough to do anything about it. Ciao, Thorsten