Remove Ban?

[Philipp Muhoray]

Am 2014-12-09 um 07:50 schrieb Avinash Patil:
> Hi Nick,
>
> I saw one of your patch to brcmfmac in Lunux wireless. For one such 
> FIXME you have added mutex lock; just because comment said need to 
> have mutex lock here.
>
> You did not have any hardware to test this patch; you simply created 
> patch because comment said so.  Rafal and other maintainers were 
> wondering- "Really! Is this fixme that simple? How come we did not get 
> it?" and then it was discovered that function which is calling this 
> one already was having mutex lock and here you cannot acquire it again..
> Rafal finally did not take that fix for obvious reason.
>
> Patches should be submitted to just to create your portfolio but they 
> should actually solve some existing design problem.
>
> Do I need to say more about your ban?
>
> Thanks,
> Avinash
>
> On Mon, Dec 8, 2014 at 9:26 PM, Nick Krause <xerofoify at gmail.com 
> <mailto:xerofoify at gmail.com>> wrote:
>
>     On Mon, Dec 8, 2014 at 10:32 AM,  <Valdis.Kletnieks at vt.edu
>     <mailto:Valdis.Kletnieks at vt.edu>> wrote:
>     > On Sun, 07 Dec 2014 22:15:13 -0500, nick said:
>     >> Greetings Fellow Developers,
>     >> I have finally learned my lesson as you can tell from my newest
>     patches being
>     >> accepted or considered in good form.
>     >
>     > Right now,all I'm seeing in linux-next from you is 2 patches that
>     > remove FIXME comments.  Given your previous history of submitting
>     > patches that failed to accurately analyze C program flow, And the
>     > commit message on one of them:
>     >
>     >     Remove FIXME comments about needing fault addresses to be
>     returned.  These
>     >     are propaagated from walk_addr_generic to gva_to_gpa and
>     from there to
>     >     ops->read_std and ops->write_std.
>     >
>     > doesn't actually address the question of how to deal with fault
>     addresses.
>     > Yes, they're propagated back - but it doesn't directly address
>     the question
>     > of how a fault address is handled (in other words, you failed to
>     show that
>     > write_std actually does the right thing once it gets whatever we
>     send back)
>     >
>     > I wouldn't hold my breath....
>     I submitted the patch. The maintainer changed the commit message
>     not me.
>     Nick
>
>     _______________________________________________
>     Kernelnewbies mailing list
>     Kernelnewbies at kernelnewbies.org
>     <mailto:Kernelnewbies at kernelnewbies.org>
>     http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Not that I have any say in this, but I feel like a ban should rather be 
justified by someone's behavior instead of incorrect patches. I guess 
most of us have send awful patches at some point, the question though is 
how we dealt with it. I'm not saying the ban should be lifted, I'm just 
saying we should communicate the right arguments for his ban (instead of 
blaming him for commit messages he didn't even write).

br,
phil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20141209/b5512575/attachment.html