On Thu, Oct 21, 2010 at 10:30 AM, Greg KH <greg@xxxxxxxxx> wrote:
...
>> Rules are meant to be broken. :P
>> Seriously, I'm only seeing downside to this rule and am missing the upside.
>
> And I'm missing the point where your comments are relevant here. ÂHow
> did you get involved in the Broadcom driver work?
Job Hazard. :) "Google is constantly evaluating new technologies."
I've spent way more than 40h looking at this driver, worked directly
with Nohee on issues I've seen, and more hours on testing? I've shared
my TODO list with Nohee more than a week ago and have sent some code
changes directly to Broadcom. I don't need to take credit for changing
"FALSE" to "false".
(no offense intended to whoever submitted that patch; Just expressing my needs.)
> I don't see any patches here from you.
Are you suggesting signed-off-by lines are the only thing worth to measure?
Testing and code review not worth anything?
Or is advice/criticism hard to accept gracefully? (e.g. "thanks, but no.")
I don't think I've deserved getting my ears boxed over this. I'm honestly
trying to be constructive. I apologize if my message came across as if
I own your sandbox.
BTW, factually, this comment is not true. Maybe overlooked the
patch I submitted recently because it was mis-attributed?
commit 93ad12cf1a8c3be46d66581a7acaa1c7fce590e2
Author: nohee ko <noheek@xxxxxxxxxxxx>
Date: Tue Oct 5 18:05:04 2010 -0700
staging: brcm80211: bug fix for n_ssids usage and update drv_info
-update drv_info so it's visible in "ethtool -i" output
-remove n_ssids usage. Fixes nullptr deref bug seen before.
Signed-off-by: Grant Grundler <grundler@xxxxxxxxxxxx>
Acked-by: Nohee Ko <noheek@xxxxxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxx>
> And most importantly, the developers involved AGREED with my "no more
> features" rule, and then instantly turned around and ignored it. ÂHow
> would you treat such a thing if you were a maintainer?
I wouldn't have made such a rule. The rule contradicts the primary
concept of drivers/staging: enable HW vendors to publish drivers, get
feedback, and shepherd the technology/device support into regular
driver tree.
However, I'm very aware it's your sandbox.
Sincere apologies if it sounded otherwise.
You've thought about my comments now.
We can move on.
thanks,
grant
ps. thanks for splitting this into a separate thread from your first
reply. ;) well done.
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
