On Wed, Aug 07, 2013 at 11:37:21AM +0200, Tom Wijsman wrote: > On Wed, 24 Jul 2013 16:09:11 -0700 > Greg KH <gre...@gentoo.org> wrote: > > > Please > > tell me exactly how you are going to evaluate which fixes I make are > > security fixes, and you know which to pick and choose from. > > 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. 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.) Hint, the line between a bugfix and a security fix is not always obvious, or even known at all. 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? How would one properly "tag" that? > 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. So that kind of makes that whole idea fall apart, right? :) sorry, greg k-h
