lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <62b60247-7838-a624-706e-b1a54785b2a5@leemhuis.info>
Date:   Mon, 22 Mar 2021 20:25:15 +0100
From:   Thorsten Leemhuis <linux@...mhuis.info>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Greg KH <gregkh@...uxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        ksummit <ksummit-discuss@...ts.linuxfoundation.org>,
        workflows@...r.kernel.org,
        Konstantin Ryabitsev <konstantin@...uxfoundation.org>
Subject: Re: RFC: create mailing list "linux-issues" focussed on issues/bugs
 and regressions



On 22.03.21 19:32, Linus Torvalds wrote:
> On Mon, Mar 22, 2021 at 8:18 AM Thorsten Leemhuis <linux@...mhuis.info> wrote:
>>
>>     I even requested a
>> "linux-regressions@...r.kernel.org" a while later, but didn't hear
>> anything back; and, sadly, about the same time I started having trouble
>> finding spare time for working on regression tracking. :-/
>
> Honestly, I'd much prefer the name 'linux-regressions' as being much
> more targeted than 'linux-issues'.

That only solves one of the two problem I'm trying to solve (albeit the
one that is more important to me). That way users still have no easy way
to query for reports about issues that are no regressions – say
something is broken and they have no idea if it once worked or never
worked at all.

> Make it clear that the list is only
> for regressions that people can describe some way, rather than some
> general "I have issues with xyz".
> 
> The more clear-cut the list is, the better, I think.

I agree to the last point and yeah, maybe regressions are the more
important problem we should work on – at least from the perspective of
kernel development.  But from the users perspective (and
reporting-issues.rst is written for that perspective) it feel a bit
unsatisfying to not have a solution to query for existing report,
regressions or not. Hmmmm...

Ciao, Thorsten

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ