On Wed, 7 Aug 2013 15:44:34 -0700 Greg KH <gre...@gentoo.org> wrote: > On Wed, Aug 07, 2013 at 11:37:21AM +0200, Tom Wijsman wrote: > > > Some kind of annotation with tags would make this kind of thing > > easy; I'm not saying it is your task to apply such annotations to > > commits, but it would rather be the task of the person who makes an > > individual patch. > > I am not going to impose an additional burden on developers to get > their patches into the stable kernel releases like this, sorry.
As I said, it's not your task; so, what you impose doesn't matter. > Can you judge which bug fixes are security ones, and which are not? > And do so for 100+ patches a week? 52 weeks a year? Great, please > do so, as no one has ever been able to do this (others have tried.) Yes, that is easy on the premise that they are annotated. > Hint, the line between a bugfix and a security fix is not always > obvious, or even known at all. The developer knows; and if not, he can probably just mark it as a fix. > And what about all of the fixes I merge in, that _are_ really security > fixes, yet we do not want to shout it out to the world at the moment? For known security bugs, being aware of a fix earlier helps. > How would one properly "tag" that? That's explained below, and would be explained in technical details. > > This would benefit multiple people; it would benefit users to know > > the amount of patches that are security and code fixes, new > > features and see them separately. It would also benefit > > distributions and system admins to filter them out, they could for > > instance drop new feature patches so they just get the fixes they > > need. > > > > It puts the power in the user's hands; allowing them to evaluate, > > pick and choose according to their own demands and needs. > > > > Implementation wise, I don't think this is any harder than the > > already existing annotations; work wise, adding a tag is easy to do. > > See above for why it is not easy at all, and, why even if we do know > some fixes are security ones, we would not tag them as such anyway. Neither seems to be a problem. > So that kind of makes that whole idea fall apart, right? :) The kernel ML will tell whether it does or not. :) -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
