public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@muc.de>
To: Greg KH <greg@kroah.com>
Cc: Chris Wright <chrisw@osdl.org>,
	torvalds@osdl.org, Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC] -stable, how it's going to work.
Date: 9 Mar 2005 20:39:36 +0100
Date: Wed, 9 Mar 2005 20:39:36 +0100	[thread overview]
Message-ID: <20050309193936.GC17918@muc.de> (raw)
In-Reply-To: <20050309183408.GB26902@kroah.com>

On Wed, Mar 09, 2005 at 10:34:08AM -0800, Greg KH wrote:
> On Wed, Mar 09, 2005 at 10:56:33AM +0100, Andi Kleen wrote:
> > Greg KH <greg@kroah.com> writes:
> > >
> > > Rules on what kind of patches are accepted, and what ones are not, into
> > > the "-stable" tree:
> > >  - It must be obviously correct and tested.
> > >  - It can not bigger than 100 lines, with context.
> > 
> > This rule seems silly. What happens when a security fix needs 150 lines? 
> 
> Then we bend the rules and accept it :)
> 
> We'll take these as a case-by-case basis...
> 
> > >  - Security patches will be accepted into the -stable tree directly from
> > >    the security kernel team, and not go through the normal review cycle.
> > >    Contact the kernel security team for more details on this procedure.
> > 
> > This also sounds like a bad rule. How come the security team has more
> > competence to review patches than the subsystem maintainers?  I can
> > see the point of overruling maintainers on security issues when they
> > are not responsive, but if they are I think the should be still the
> > main point of contact.
> 
> Security fixes go from the security team to Linus's tree directly, and
> usually the subsystem maintainer has already been notified and has
> reviewedit.  At that point in time, they are public and accepted into

What guarantees that?

Basically what I would like to avoid is that the security team
merges something through the backdoor that the maintainer considers crap.

If anything you should have a rule like

"Send to maintainer. If he doesn't ACK in 24h send it directly"


> mainline, and need to be made availble to the -stable users as soon as
> possible.
> 
> That is why the "fast track" is going to happen, the patch really was
> reviewed properly, just not in public :)

Well, when you really want to have such formal rules (which is a novelty in 
Linux space BTW, for many years we did fine with unwritten rules)  then you
should spell it out completely. Or alternatively drop all the formal
rules and do it informally like it was always done.


-Andi

  reply	other threads:[~2005-03-10  6:19 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-09  7:28 [RFC] -stable, how it's going to work Greg KH
2005-03-09  9:56 ` Andi Kleen
2005-03-09 10:10   ` Arjan van de Ven
2005-03-09 10:17     ` Russell King
2005-03-09 10:24       ` Arjan van de Ven
2005-03-09 10:32         ` Russell King
2005-03-09 10:28       ` Andi Kleen
2005-03-09 14:20   ` Marcelo Tosatti
2005-03-09 18:00   ` Alan Cox
2005-03-09 18:29     ` Greg KH
2005-03-09 18:29     ` Chris Wright
2005-03-09 19:30     ` Andi Kleen
2005-03-09 18:28   ` Chris Wright
2005-03-09 19:44     ` Andi Kleen
2005-03-09 20:16       ` Chris Wright
2005-03-09 22:49       ` Russell King
2005-03-09 18:34   ` Greg KH
2005-03-09 19:39     ` Andi Kleen [this message]
2005-03-09 20:03       ` Greg KH
2005-03-09 20:25   ` Bill Davidsen
2005-03-10 10:00 ` Neil Brown
2005-03-10 10:17   ` Arjan van de Ven
2005-03-11  1:49     ` Neil Brown
2005-03-11  4:58       ` Chris Friesen
2005-03-11  7:07         ` Andi Kleen
2005-03-10 16:43   ` Greg KH
2005-03-10 17:27     ` Lee Revell
2005-03-10 17:31       ` Greg KH
2005-03-10 18:25         ` Lee Revell
2005-03-11 10:13           ` Pavel Machek
2005-03-10 17:43       ` Chris Wright
2005-03-10 17:51         ` Lee Revell
2005-03-10 17:44       ` Linus Torvalds
2005-03-11  0:10     ` Neil Brown
2005-03-11  2:43       ` J. Bruce Fields

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=20050309193936.GC17918@muc.de \
    --to=ak@muc.de \
    --cc=akpm@osdl.org \
    --cc=chrisw@osdl.org \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.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