> We have done a code review of what has been proposed and we believe it is > incomplete. We don't think that in its current state it will serve Linux as > well as we all want it to.
I fully appreciate you're intent, but I can't imagine how you can think that it wont serve Linux in it's current state when it does in fact serve Linux (and its users) in it's current state. What doesn't serve Linux (and its users) is blocking patches in the hopes of you taking two weeks to get two non-technical departments to approve you and/or some other engineer(s) to do what you consider a better job. You cannot guarantee that this will even be "approved" and you can't guarantee that the end will result will come at any reasonable point in time after that arbitrary waiting period. The delay serves no purpose. LSIs solution to this problem with only be a superset of this patch. This patch will be unchanged from your solution because there is absolutely no other way to implement this. It's not like there is a technical discussion about how the patch works. It's plain and simple. So I say include this patch. If you get some sort of ok by your bobbling heads to complete the work, then you can even tell them "it's partly done already." No manager can argue with less work (aka investment). -- Servergy : http://www.servergy.com/ SwissDisk : http://www.swissdisk.com/ Ubuntu : http://www.ubuntu.com/ My Blog : http://ben-collins.blogspot.com/
signature.asc
Description: Message signed with OpenPGP using GPGMail
