public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
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 --]

  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