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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87fsp25g28.fsf@meer.lwn.net>
Date:   Tue, 01 Feb 2022 16:21:19 -0700
From:   Jonathan Corbet <corbet@....net>
To:     Thorsten Leemhuis <linux@...mhuis.info>, linux-doc@...r.kernel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     workflows@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Randy Dunlap <rdunlap@...radead.org>,
        regressions@...ts.linux.dev,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Lukas Bulwahn <lukas.bulwahn@...il.com>
Subject: Re: [PATCH v4 2/3] docs: regressions*rst: rules of thumb for
 handling regressions

Thorsten Leemhuis <linux@...mhuis.info> writes:

One thing that caught my eye this time around...

> + * Address regressions in stable, longterm, or proper mainline releases with
> +   more urgency than regressions in mainline pre-releases. That changes after
> +   the release of the fifth pre-release, aka "-rc5": mainline then becomes as
> +   important, to ensure all the improvements and fixes are ideally tested
> +   together for at least one week before Linus releases a new mainline version.

Is that really what we want to suggest?  I ask because (1) fixes for
stable releases need to show up in mainline first anyway, and (2) Greg
has often stated that the stable releases shouldn't be something that
most maintainers need to worry about.  So if the bug is in mainline,
that has to get fixed first, and if it's something special to a stable
release, well, then the stable folks should fix it :)

> + * Fix regressions within two or three days, if they are critical for some
> +   reason -- for example, if the issue is likely to affect many users of the
> +   kernel series in question on all or certain architectures. Note, this
> +   includes mainline, as issues like compile errors otherwise might prevent many
> +   testers or continuous integration systems from testing the series.
> +
> + * Aim to merge regression fixes into mainline within one week after the culprit
> +   was identified, if the regression was introduced in a stable/longterm release
> +   or the development cycle for the latest mainline release (say v5.14). If
> +   possible, try to address the issue even quicker, if the previous stable
> +   series (v5.13.y) will be abandoned soon or already was stamped "End-of-Life"
> +   (EOL) -- this usually happens about three to four weeks after a new mainline
> +   release.

How much do we really think developers should worry about nearly-dead
stable kernels?  We're about to tell users they shouldn't be running the
kernel anyway...

Thanks,

jon

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ