All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Wright <chrisw@osdl.org>
To: Andi Kleen <ak@muc.de>
Cc: Chris Wright <chrisw@osdl.org>, Greg KH <greg@kroah.com>,
	torvalds@osdl.org, Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC] -stable, how it's going to work.
Date: Wed, 9 Mar 2005 12:16:31 -0800	[thread overview]
Message-ID: <20050309201631.GC5389@shell0.pdx.osdl.net> (raw)
In-Reply-To: <20050309194401.GD17918@muc.de>

* Andi Kleen (ak@muc.de) wrote:
> On Wed, Mar 09, 2005 at 10:28:22AM -0800, Chris Wright wrote:
> > * Andi Kleen (ak@muc.de) wrote:
> > > Greg KH <greg@kroah.com> writes:

> > > One rule I'm missing:
> > > 
> > > - It must be accepted to mainline. 
> > 
> > This can violate the principle of keeping fixes simple for -stable tree.
> > And Linus/Andrew don't want to litter mainline with patch series that
> > do simple fix followed by complete fix meant for developement branch.
> 
> But it risks code drift like we had in 2.4 with older kernels 
> having more fixes than the newer kernel. And that way lies madness.
> 
> I think it is very very important to avoid this.
> 
> If you prefer you can rewrite the rule like
> 
> "Fix must in mainline first. In exceptional cases when the fix 
> in mainline is too intrusive or risky a simpler version of the patch
> can be applied to stable. In this case the mainline fix must be already
> accepted. For most cases the full fix should be applied to avoid code drift"

I think we've all agreed that's the intention.

> > I agree, it's a good rule, but these should be small, temporal diffs
> > from mainline.  For example, -ac tree will sometimes do the simpler fix,
> > whereas mainline does proper complete fix.
> 
> You make it sound like all patches are super complicated and 
> not suitable for backporting.

I didn't think I did, that's why I said 'sometimes'.  Just acknowledging
what does really happen.

> > They don't, the security patches should still be reviewed by subsystem
> > maintainer.  Point here is, sometimes there's disclosure coordination
> > happening as well.
> 
> Ok, how does it coordinate with the vendor-sec process? 
> And at what point is the subsystem maintainer notified.

That's part of the vendor coordination mentioned in the policy.  And
subsystem maintainer is notified as part of vetting the issue/solution,
as stated in the policy.

> The security thing seems to be still quite half backed to me...

Take a look at the policy I posted last night and give me suggestions
for improvements.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

  reply	other threads:[~2005-03-09 21:23 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 [this message]
2005-03-09 22:49       ` Russell King
2005-03-09 18:34   ` Greg KH
2005-03-09 19:39     ` Andi Kleen
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=20050309201631.GC5389@shell0.pdx.osdl.net \
    --to=chrisw@osdl.org \
    --cc=ak@muc.de \
    --cc=akpm@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 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.