1 |
On Wed, Aug 07, 2013 at 11:37:21AM +0200, Tom Wijsman wrote: |
2 |
> On Wed, 24 Jul 2013 16:09:11 -0700 |
3 |
> Greg KH <gregkh@g.o> wrote: |
4 |
> |
5 |
> > Please |
6 |
> > tell me exactly how you are going to evaluate which fixes I make are |
7 |
> > security fixes, and you know which to pick and choose from. |
8 |
> |
9 |
> Some kind of annotation with tags would make this kind of thing easy; |
10 |
> I'm not saying it is your task to apply such annotations to commits, but |
11 |
> it would rather be the task of the person who makes an individual patch. |
12 |
|
13 |
I am not going to impose an additional burden on developers to get their |
14 |
patches into the stable kernel releases like this, sorry. |
15 |
|
16 |
Can you judge which bug fixes are security ones, and which are not? And |
17 |
do so for 100+ patches a week? 52 weeks a year? Great, please do so, |
18 |
as no one has ever been able to do this (others have tried.) |
19 |
|
20 |
Hint, the line between a bugfix and a security fix is not always |
21 |
obvious, or even known at all. |
22 |
|
23 |
And what about all of the fixes I merge in, that _are_ really security |
24 |
fixes, yet we do not want to shout it out to the world at the moment? |
25 |
How would one properly "tag" that? |
26 |
|
27 |
> This would benefit multiple people; it would benefit users to know the |
28 |
> amount of patches that are security and code fixes, new features and |
29 |
> see them separately. It would also benefit distributions and system |
30 |
> admins to filter them out, they could for instance drop new feature |
31 |
> patches so they just get the fixes they need. |
32 |
> |
33 |
> It puts the power in the user's hands; allowing them to evaluate, pick |
34 |
> and choose according to their own demands and needs. |
35 |
> |
36 |
> Implementation wise, I don't think this is any harder than the already |
37 |
> existing annotations; work wise, adding a tag is easy to do. |
38 |
|
39 |
See above for why it is not easy at all, and, why even if we do know |
40 |
some fixes are security ones, we would not tag them as such anyway. |
41 |
|
42 |
So that kind of makes that whole idea fall apart, right? :) |
43 |
|
44 |
sorry, |
45 |
|
46 |
greg k-h |