On Fri, Aug 09, 2013 at 10:34:58AM +0200, Tom Wijsman wrote: > On Thu, 8 Aug 2013 15:32:45 -0700 > Greg KH <gre...@gentoo.org> wrote: > > > On Thu, Aug 08, 2013 at 04:37:32AM +0200, Tom Wijsman wrote: > > > On Wed, 7 Aug 2013 15:44:34 -0700 > > > Greg KH <gre...@gentoo.org> wrote: > > > > > > > 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. > > > > What do you mean by that? I am the upstream stable kernel maintainer, > > as well as a subsystem maintainer. I don't want to do the extra work > > of tagging all of my stable patches with this type of information, I > > can barely keep on top of the ones that I have to mark for stable as > > it is. > > > > > ... > > > > But I will argue that you can not annotate them "properly". That is > > imposing more work on me, a subsystem maintainer, that I will not do. > > Not just stable patches, but any patch; why delay till after the fact? > > Tagging at the time of committing is just a few extra characters.
And don't people do that already with their changelog comments in the kernel? No, not in any "offical" format, but that's been rejected numerous times. Just read the commits to find out what is resolved, if anything is known at that point in time, if you are curious. > > > > 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. > > > > Ok, so you have just now divided everything into "fix" or "feature". > > As the "feature" patches are quite obvious, everything else must be > > "fix". So why tag anything, your classification is already done for > > you. > > If they are obvious, what's so hard abut tagging them? Because it's extra work that is pointless. You do realize just how many patches go into the kernel every day, right? Doing anything to a patch will slow things down, and given the huge number of the, odds are a percentage will be wrong anyway. > No classification is done if there is no single command to obtain them. I don't understand what you mean by this. > > > > 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. > > > > I don't understand what you mean here at all. > > Neither do I understand what you mean by not shouting it out; so, > unless you have argumentation to not shout it out, I'm in the belief > that the faster one is able to apply a security fix, the more secure he > is as a result. If not shouting it out makes things more secure, then > please state me how and why; because it only gives attackers more time. The kernel team does not explicitly call out security fixes when they go into the kernel for a variety of good reasons, all of which have been argued and debated numerous times for many years. See the linux-kernel mailing list archives if you are curious, I'm not going to get into that argument here, except to point out that the current behavior is probably not going to change. greg k-h
