On 7/12/2013 3:05 AM, Greg KH wrote:
On Fri, Jul 12, 2013 at 02:53:37AM +0200, Rafael J. Wysocki wrote:
On 7/12/2013 2:37 AM, Greg KH wrote:
On Fri, Jul 12, 2013 at 02:32:07AM +0200, Rafael J. Wysocki wrote:
On 7/12/2013 2:29 AM, Greg KH wrote:
On Fri, Jul 12, 2013 at 02:22:23AM +0200, Rafael J. Wysocki wrote:
On 7/12/2013 1:30 AM, gregkh@xxxxxxxxxxxxxxxxxxx wrote:
The patch below was submitted to be applied to the 3.10-stable tree.
I fail to see how this patch meets the stable kernel rules as found at
Documentation/stable_kernel_rules.txt.
I could be totally wrong, and if so, please respond to
<stable@xxxxxxxxxxxxxxx> and let me know why this patch should be
applied. Otherwise, it is now dropped from my patch queues, never to be
seen again.
Well, you may not agree with that obviously, but I consider cases
when the function header declared in a header file doesn't match the
definition of that function as serious breakage. Normally, it would
cause a build failure to happen and the fact that it incidentally
doesn't cause it for reasons not entirely clear to me doesn't really
matter.
If it doesn't cause a build failure, or any other "user-visable"
problem, it really shouldn't be a stable patch, right?
Can you guarantee that it won't cause a build failure to happen with
a future GCC or a different compiler?
Nope, and if it does, I'll be glad to apply it then :)
And will you remember about it? Because I won't. :-)
And the same guys telling you how they have problems because there
are too many commits in -stable will have to fix it by themselves
and carry the fix. Good for them.
And then Debian will dig out the fix and send it for inclusion, like
they always do :)
Well, in fact, the reason I marked this particular one for 3.10-stable
was because it fixed fresh 3.10 breakage (that happened after 3.10-rc7
to be precise), so I thought it would be good to fix it in 3.10.1 so as
to reduce its exposure.
I have two more fixes of that kind and I'm going to mark them as "CC
3.10-stable" regardless of your current pushback mode. Sorry in advance.
This particular stuff is not what's causing the problems they're
seeing to happen, however, so I'm not really sure what you're trying
to achieve by pushing back this way. Surely some really important
stuff is going to be missing in -stable going forward, but I don't
work for a distro any more, so why should I care? :-)
I'm trying to push back on the obvious "this really shouldn't be in
-stable" patches. Each patch added takes time (my review time, others
review time, etc.) so when people start adding "\n" additions to debug
printk messages, that has the chance to soon swamp me with non-relevant
patches.
Oh, missing newline in printk messages is annoying. Is it annoying
enough? If I were one of the people complaining about that, it
certainly would be for me.
If you don't feel comfortable sending a patch to Linus after -rc4, I
don't think it should be in the -stable trees.
I would send both of the patches in question to Linus after -rc4,
because (1) they are simple enough and (2) I don't see a valid reason to
sit on things like these for weeks as they obviously fix things and the
risk from applying them in zero. I wouldn't send them to him after
-rc6, but that's a different matter.
Quite frankly, to me the only technically valid reason for rejecting
commits marked for -stable inclusion by maintainers is "that thing is
too risky". Anything else is a matter of differing opinions.
---------------------------------------------------------------------
Intel Technology Poland sp. z o.o.
z siedziba w Gdansku
ul. Slowackiego 173
80-298 Gdansk
Sad Rejonowy Gdansk Polnoc w Gdansku,
VII Wydzial Gospodarczy Krajowego Rejestru Sadowego,
numer KRS 101882
NIP 957-07-52-316
Kapital zakladowy 200.000 zl
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html