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: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <17c526d0c5f8ed8584f7bee9afe1b73753d1c70b.camel@gmx.com>
[not found] ` <20201117080141.GA6275@amd>
2020-11-17 20:53 ` Suggestion: Lengthen the review period for stable releases from 48 hours to 7 days 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox