From: Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de>
To: Hussam Al-Tayeb <ht990332@gmx.com>
Cc: stable@vger.kernel.org
Subject: Re: Suggestion: Lengthen the review period for stable releases from 48 hours to 7 days.
Date: Tue, 17 Nov 2020 23:29:16 +0100 [thread overview]
Message-ID: <1605651898@msgid.manchmal.in-ulm.de> (raw)
In-Reply-To: <f4cb8d3de515e97d409fa5accca4e9965036bdb5.camel@gmx.com>
[-- Attachment #1: Type: text/plain, Size: 1602 bytes --]
>> On Sat 2020-11-14 17:40:36, Hussam Al-Tayeb wrote:
>>> Hello. I would like to suggest lengthening the review period for stable
>>> releases from 48 hours to 7 days.
>>> The rationale is that 48 hours is not enough for people to test those
>>> stable releases and make sure there are no regressions for
>>> particular workflows.
Disclaimer: I am mostly a user of stable
It's hard to make a good decision here. I share your position the 48-ish
hours are a fairly short amound of time, and increasing it would grant
more time for tests. As for me, I might resume testing -rc on a regular
base as I used to in the past - which is a time-consuming procedure, and
since I do that as a hobby, sometimes more important things are in the
way. But I have to concede the number of issues that occured only here
was never high, and I don't expect it would grow significantly.
On the other hand the pace of the stable patches became fairly high¹, so
during a week of -rc review a *lot* of them will queue up and I predict
we'll see requests for fast-laning some of them. Also, a release would
immediately be followed by the next -rc review period, a procedure that
gives me a bad feeling.
So for me, I'd appreciate an extension of the review period, even if
it's just four days. But I understand if people prefer to keep the
procedures simple, and get fixes out of the door as soon as possible.
My 2¢
Christoph
¹ If somebody made statistics on the development of the number of
patches for stable kernels (in count/second), I'd be curious to see
the numbers.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2020-11-17 22:37 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-14 15:40 Suggestion: Lengthen the review period for stable releases from 48 hours to 7 days Hussam Al-Tayeb
2020-11-14 19:16 ` Hussam Al-Tayeb
2020-11-17 8:01 ` Pavel Machek
2020-11-17 20:53 ` Hussam Al-Tayeb
2020-11-17 22:29 ` Christoph Biedl [this message]
2020-11-18 7:20 ` Greg KH
2020-11-18 14:09 ` Sasha Levin
2020-11-18 18:02 ` Hussam Al-Tayeb
2020-11-18 18:12 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1605651898@msgid.manchmal.in-ulm.de \
--to=linux-kernel.bfrz@manchmal.in-ulm.de \
--cc=ht990332@gmx.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.