* Andi Kleen ([EMAIL PROTECTED]) wrote:
> Greg KH <[EMAIL PROTECTED]> 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?
>
> Better maybe a rule like "The patch should be the minimal and safest
> change to fix an issue". But see below for an exception.
It's just a guideline to scope the work. But a fixed size is probably
less meaningful than your wording.
> > - It must fix only one thing.
> > - It must fix a real bug that bothers people (not a, "This could be a
> > problem..." type thing.)
> > - It must fix a problem that causes a build error (but not for things
> > marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
> > security issue, or some "oh, that's not good" issue. In short,
> > something critical.
> > - No "theoretical race condition" issues, unless an explanation of how
> > the race can be exploited.
> > - It can not contain any "trivial" fixes in it (spelling changes,
> > whitespace cleanups, etc.)
> > - It must be accepted by the relevant subsystem maintainer.
>
> > - It must follow Documentation/SubmittingPatches rules.
>
> 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.
> That is what big enterprise distributions often require and I think
> it's a good rule. Otherwise you risk code and feature set drift
> and we don't want to repeat the 2.4 mistakes again where some
> subsystems had more fixes in 2.4 than 2.6.
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.
> Also your rules encourage to do different patches for -stable
> (e.g. with less comment changes etc.) than for mainline. I don't
> think that's a very good thing. Sometimes it is unavoidable
> and sometimes the mainline patches are just too big and intrusive,
> but in general it's imho best to apply the same patches
> to mainline and backport trees. This has also the advantage
> that the patch is best tested as possible; slimmed down patches
> usually have a risk of malfunction.
>
> If a mainline patch violates too many of your other rules
> ("Fixes one thing; doesn't do cosmetic changes etc.") perhaps
> the mainline patch just needs to be improved.
Good point.
> So in general there should be a preference to apply the same
> patch as mainline, unless it is very big.
Agreed.
> > - 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.
They don't, the security patches should still be reviewed by subsystem
maintainer. Point here is, sometimes there's disclosure coordination
happening as well.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
