ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Justin Forbes <jforbes@redhat.com>
To: Laura Abbott <labbott@redhat.com>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	ksummit <ksummit-discuss@lists.linuxfoundation.org>
Subject: Re: [Ksummit-discuss] [MAINTAINER SUMMIT] Stable trees and release time
Date: Tue, 4 Sep 2018 16:22:59 -0500	[thread overview]
Message-ID: <CAFbkSA3Zjojhb4uUFrdpJUTSWz1V9RbG_EL83roQY3bzX80i-g@mail.gmail.com> (raw)
In-Reply-To: <5c9c41b2-14f9-41cc-ae85-be9721f37c86@redhat.com>

On Tue, Sep 4, 2018 at 3:58 PM, Laura Abbott <labbott@redhat.com> wrote:
> I'd like to start a discussion about the stable release cycle.
>
> Fedora is a heavy user of the most recent stable trees and we
> generally do a pretty good job of keeping up to date. As we
> try and increase testing though, the stable release process
> gets to be a bit difficult. We often run into the problem where
> release .Z is officially released and then .Z+1 comes
> out as an -rc immediately after. Given Fedora release processes,
> we haven't always finished testing .Z by the time .Z+1 comes
> out. What to do in this situation really depends on what's in
> .Z and .Z+1 and how stable we think things are. This usually
> works out fine but a) sometimes we guess wrong and should have
> tested .Z more b) we're only looking to increase testing.
>
> What I'd like to see is stable updates that come on a regular
> schedule with a longer -rc interval, say Sunday with
> a one week -rc period. I understand that much of the current
> stable schedule is based on Greg's schedule. As a distro
> maintainer though, a regular release schedule with a longer
> testing window makes it much easier to plan and deliver something
> useful to our users. It's also a much easier sell for encouraging
> everyone to pick up every stable update if there's a known
> schedule. I also realize Greg is probably reading this with a very
> skeptical look on his face so I'd be interested to hear from
> other distro maintainers as well.
>

This has been a fairly recent problem. There was a roughly weekly
cadence for a very long time and that was pretty easy to work with.  I
know that some of these updates do fix embargoed security issues that
we don't find out are actual fixes until later, but frequently in
those cases, the fixes are pushed well before embargo lifts, and they
could be fit into a weekly cadence.  Personally I don't have a problem
with the 3 day rc period, but pushing 2 kernels a week can be a
problem for users. (skipping a stable update is also a problem for
users.)  What I would prefer is 1 stable update per week with an
exception for *serious* security issues, where serious would mean
either real end user impact or high profile lots of press users are
going to be wondering where a fix is.

Justin

  parent reply	other threads:[~2018-09-04 21:23 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-04 20:58 Laura Abbott
2018-09-04 21:12 ` Jiri Kosina
2018-09-05 14:31   ` Greg KH
2018-09-04 21:22 ` Justin Forbes [this message]
2018-09-05 14:42   ` Greg KH
2018-09-05 15:10     ` Mark Brown
2018-09-05 15:10     ` Sasha Levin
2018-09-05 16:19     ` Guenter Roeck
2018-09-05 18:31     ` Laura Abbott
2018-09-05 21:23     ` Justin Forbes
2018-09-06  2:17     ` Eduardo Valentin
2018-09-04 21:33 ` Sasha Levin
2018-09-04 21:55   ` Guenter Roeck
2018-09-04 22:03     ` Laura Abbott
2018-09-04 23:14       ` Sasha Levin
2018-09-04 23:43         ` Guenter Roeck
2018-09-05  1:17           ` Laura Abbott
2018-09-06  3:56             ` Benjamin Gilbert
2018-09-04 21:58   ` Laura Abbott
2018-09-05  4:53     ` Sasha Levin
2018-09-05  6:48   ` Jiri Kosina
2018-09-05  8:16     ` Jan Kara
2018-09-05  8:32       ` Jiri Kosina
2018-09-05  8:56         ` Greg KH
2018-09-05  9:13           ` Geert Uytterhoeven
2018-09-05  9:33             ` Greg KH
2018-09-05 10:11           ` Mark Brown
2018-09-05 14:44             ` Steven Rostedt
2018-09-05  9:58         ` James Bottomley
2018-09-05 10:47           ` Mark Brown
2018-09-05 12:24             ` James Bottomley
2018-09-05 12:53               ` Jiri Kosina
2018-09-05 13:05                 ` Greg KH
2018-09-05 13:15                   ` Jiri Kosina
2018-09-05 14:00                     ` Greg KH
2018-09-05 14:06                     ` Sasha Levin
2018-09-05 21:02                       ` Jiri Kosina
2018-09-05 16:39                 ` James Bottomley
2018-09-05 17:06                   ` Dmitry Torokhov
2018-09-05 17:33                   ` Steven Rostedt
2018-09-05 13:03               ` Takashi Iwai
2018-09-05 13:27                 ` Daniel Vetter
2018-09-05 14:05                   ` Greg KH
2018-09-05 15:54                     ` Daniel Vetter
2018-09-05 16:19                       ` Sasha Levin
2018-09-05 16:26                         ` Daniel Vetter
2018-09-05 19:09                           ` Sasha Levin
2018-09-05 20:18                             ` Sasha Levin
2018-09-05 20:33                               ` Daniel Vetter
2018-09-05 14:20                 ` Sasha Levin
2018-09-05 14:30                   ` Takashi Iwai
2018-09-05 14:41                     ` Sasha Levin
2018-09-05 14:46                       ` Takashi Iwai
2018-09-05 14:54                         ` Sasha Levin
2018-09-05 15:12                           ` Takashi Iwai
2018-09-05 15:19                           ` Thomas Gleixner
2018-09-05 15:29                             ` Sasha Levin
2018-09-05 13:16               ` Mark Brown
2018-09-05 14:27                 ` Sasha Levin
2018-09-05 14:50                   ` Mark Brown
2018-09-05 15:00                     ` Sasha Levin
2018-09-05 10:28       ` Thomas Gleixner
2018-09-05 11:20         ` Jiri Kosina
2018-09-05 14:41           ` Thomas Gleixner
2018-09-05 15:18             ` Steven Rostedt
2018-09-06  8:48               ` Thomas Gleixner
2018-09-06 12:47                 ` Thomas Gleixner
2018-09-04 21:49 ` Guenter Roeck
2018-09-04 22:06   ` Laura Abbott
2018-09-04 23:35     ` Guenter Roeck
2018-09-05  1:45       ` Laura Abbott
2018-09-05  2:54         ` Guenter Roeck
2018-09-05  8:31           ` Jan Kara
2018-09-05  3:44 ` Eduardo Valentin

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=CAFbkSA3Zjojhb4uUFrdpJUTSWz1V9RbG_EL83roQY3bzX80i-g@mail.gmail.com \
    --to=jforbes@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=labbott@redhat.com \
    /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