[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20121214.153825.1087482329989146130.davem@davemloft.net>
Date: Fri, 14 Dec 2012 15:38:25 -0500 (EST)
From: David Miller <davem@...emloft.net>
To: caiqian@...hat.com
Cc: netdev@...r.kernel.org
Subject: Re: request to queue patches for stable
From: CAI Qian <caiqian@...hat.com>
Date: Mon, 10 Dec 2012 21:03:15 -0500 (EST)
>
>
> ----- Original Message -----
>> From: "David Miller" <davem@...emloft.net>
>> To: caiqian@...hat.com
>> Cc: greg@...ah.com, stable@...r.kernel.org, mbizon@...ebox.fr, ja@....bg
>> Sent: Friday, December 7, 2012 11:23:21 AM
>> Subject: Re: [PATCH] ipv4: do not cache looped multicasts
>>
>> From: CAI Qian <caiqian@...hat.com>
>> Date: Thu, 6 Dec 2012 21:56:35 -0500 (EST)
>>
>> > OK, I have a few network patches in the queue that looks applicable
>> > to
>> > the stable as well. I think I'll send them out here too to seek
>> > their
>> > ACKs. David, please let me know if I should stop doing this.
>>
>> Please stop doing this.
>>
>> If you want networking patches to reach stable, first
>> consult:
>>
>> http://patchwork.ozlabs.org/bundle/davem/stable/
>>
>> to see if the patch you want isn't queued up already.
>>
>> If it is not, ask me to queue it up on netdev@...r.kernel.org
>>
>> But note that I like to let networking patches "cook" upstream
>> in Linus's tree for a certain amount of time before I submit
>> them to -stable. There can be up to even a week or two.
> Dave, the following patches looks applicable for the stable
> releases. Please queue them up if you agree.
>
> 0e376bd0b791ac6ac6bdb051492df0769c840848 (for 3.0.x, 3.4.x and 3.6.x)
> e196c0e579902f42cf72414461fb034e5a1ffbf7 (for 3.0.x, 3.4.x and 3.6.x)
> 6e51fe7572590d8d86e93b547fab6693d305fd0d (for 3.0.x, 3.4.x and 3.6.x)
> e1a676424c290b1c8d757e3860170ac7ecd89af4 (for 3.6.x)
> 636174219b52b5a8bc51bc23bbcba97cd30a65e3 (for 3.6.x)
What is the point of my publishing the pending networking -stable
queue if you're not even going to check it? Those last two patches
were already queued up.
Furthermore, it is erroneous to suggest the -ENOMEM SCTP fix without
the memory leak fix that happens in the commit right before it.
I've queued things up appropriately, but I really don't appreciate
how you've handled this at all. It makes a lot more work for me than
necessary.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists