On Mon, Mar 04, 2013 at 09:14:26PM +0100, Thomas Bork wrote: > On 04.03.2013 07:13, Willy Tarreau wrote: > > >Thomas, you don't need to ask for each and every patch you find missing > >from 2.6.32 *why* it's not there, as I explained to you in my last e-mail, > >many patches are missing. > > Willy, sorry - but such a mail from you doesn't reached me. OK, it was in the other thread in the same week about a missing patch, where basically I said that many patches are missing and that it is expected and normal. I might still have it if you want it again. > >Better ask if we could include it and why you think it makes sense (eg: > >you have verified that it fixes one problem you're experiencing), and > >we'll all save a lot of time. > > I wrote on 30.01.2013 to you: > > [...] > 2. > Revert "block: improve queue_should_plug() by looking at IO depths" > http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commitdiff;h=79da0644a8e0838522828f106e4049639eea6baf;hp=9f3a6284880ceea452903e2043c88d7226736318 I trust you on this, but this time it's me who didn't get this e-mail (I can't find any trace of it here). Care to bounce it back to me ? > This was reverted 2010-02-23 in 2.6.33(!) and is there till now in > 2.6.34.y. This makes installing our system on usb sticks more usefully. > [...] > > The points 1. to 5. and the corresponding patches in my mail all fixed > problems for us. But I received no answer from you. Indeed, I don't have it. I know that from time to time I lose some mails (and I'm certain that I'm not the only one), so always consider that something not acked is not received, especially when it's asked for inclusion. > Thats okay, you are busy. I am but the reason here was that the message got lost somewhere between your fingers and my eyes :-) > The reason why I ask here, why a patch for a problem fix is in 2.6.33 > and all following kernels but not in 2.6.32, is, that there may be a > reason for this. No, there is no reason that I'm aware of. Quite frankly, I rarely have reasons for not merging a patch except : - missed it - failed to apply - too complex backport - rejected by someone with more knowledge than me The first 3 reasons are easily covered by a request for inclusion. The last one will be noticed either by me because I'll remind about it, or by their respective authors during the review. So you should absolutely consider that requesting inclusion is the most efficient way to get the patch merged or get a NAK with a proper reason. > Because I followed not every discussions here and maybe found the reason > not, because I searched the net badly. No problem, I'm not of the people who would call you names because you forward to me some work you've done, and I know that it's not easy to dig in the high volume of e-mails in archives. > Sorry for the noise. You're welcome! And please send the one above back to me again so that I can queue it. Willy -- 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