All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Josh Boyer <jwboyer@fedoraproject.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	stable <stable@vger.kernel.org>,
	lwn@lwn.net, Guenter Roeck <linux@roeck-us.net>,
	Hugh Dickins <hughd@google.com>,
	Johannes Berg <johannes@sipsolutions.net>,
	Borislav Petkov <bp@alien8.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Proposed stable release changes
Date: Tue, 20 Aug 2013 16:57:00 -0700	[thread overview]
Message-ID: <20130820235700.GA7209@kroah.com> (raw)
In-Reply-To: <CA+5PVA4s8D6Hkvj7c4Hpw6MOefZG4BEEWZjWb4XHW+k4n_sWjA@mail.gmail.com>

On Tue, Aug 20, 2013 at 07:40:49PM -0400, Josh Boyer wrote:
> On Tue, Aug 20, 2013 at 6:40 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > Hi all,
> >
> > Given that I had to just revert a patch in the recent stable releases
> > that didn't get enough time to "bake" in Linus's tree (or in -next), I
> > figured it was worth discussing some possible changes with how "fast" I
> > pick up patches for stable releases.
> >
> > So, how about this proposal:
> >
> > - I will wait for a -rc to come out with the patch in it before putting
> >   it into a stable release, unless:
> >         - the maintainer ACKs it, or sends it directly (like DaveM does
> >           for networking patches)
> >         - I have seen enough discussion about a patch to show that it
> >           really does fix something / is good / doesn't cause problems.
> >         - obviously safe, i.e. "add a device id" type thing.
> >
> > Given that we have -rc releases every week, except for the initial -rc1
> > release, I don't think this will really cause any major delays.
> >
> > Also, now that we are about to head into my busy "travel season", odds
> > are, I'll be at least a week behind anyway, so this would probably start
> > happening without an "official" change.  It's been a boring summer, I've
> > been able to keep up with the stable stuff really easily, causing
> > problems like this :)
> >
> > Objections?  Comments?
> 
> I like this overall.  The only thing I might change is "wait for -rc2"
> for patches tagged with CC: stable that go in during the merge window.
>  It seems those are the ones that tend to bite us.

Maintainers can always tag their patches to have me hold off until -rc2
for that.

And, given the huge number of patches for stable that come in during
the -rc1 merge window, there's no way I can get to them all before -rc2
comes out, so this will probably end up being the case for most of them
anyway.

thanks,

greg k-h

  reply	other threads:[~2013-08-20 23:57 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-20 22:40 Proposed stable release changes Greg KH
2013-08-20 22:58 ` Willy Tarreau
2013-08-20 23:12   ` Greg KH
2013-08-20 23:57     ` Guenter Roeck
2013-08-21  5:24     ` Willy Tarreau
2013-08-20 23:04 ` Nicholas A. Bellinger
2013-08-20 23:12   ` Greg KH
2013-08-20 23:11 ` Guenter Roeck
2013-08-20 23:17   ` Greg KH
2013-08-21  0:11     ` Guenter Roeck
2013-08-21  0:42       ` Greg KH
2013-08-20 23:40 ` Josh Boyer
2013-08-20 23:57   ` Greg KH [this message]
2013-08-21  0:41     ` Josh Boyer
2013-08-21  0:49       ` Greg KH
2013-08-21  1:03         ` Josh Boyer
2013-08-21  1:11           ` Guenter Roeck
2013-08-21 18:15           ` Greg KH
2013-08-21  5:38         ` Willy Tarreau
2013-08-21 13:37           ` Steven Rostedt
2013-08-21 17:23             ` Jochen Striepe
2013-08-21 17:58               ` Steven Rostedt
2013-08-21 20:07                 ` Borislav Petkov
2013-08-21 20:16                   ` Greg KH
2013-08-21 21:00                     ` Borislav Petkov
2013-08-21 13:42       ` Steven Rostedt
2013-08-21 14:17         ` Willy Tarreau
2013-08-21 14:54           ` Steven Rostedt
2013-08-24 18:45             ` Stefan Richter
2013-08-21 13:48 ` Borislav Petkov
2013-08-21 17:08   ` Greg KH
2013-08-21 18:20 ` Stephen Warren
2013-08-21 18:36   ` Linus Torvalds
2013-08-21 20:00     ` Borislav Petkov
2013-08-21 20:54       ` Tony Luck
2013-08-22  8:57         ` Borislav Petkov
2013-08-22 10:59         ` Geert Uytterhoeven
2013-08-22  0:05     ` Stephen Rothwell

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=20130820235700.GA7209@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=hughd@google.com \
    --cc=johannes@sipsolutions.net \
    --cc=jwboyer@fedoraproject.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=lwn@lwn.net \
    --cc=stable@vger.kernel.org \
    --cc=torvalds@linux-foundation.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.