Greetings Fellow Developers, I have finally learned my lesson as you can tell from my newest patches being accepted or considered in good form. In addition if people are willing to trust me again, I would like to remove my ban in order to help out more. If not I understand completely and will try to improve my trust from the developers on the kernel list even more. Thanks for the Understanding, Nick
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....
On Mon, Dec 8, 2014 at 10:32 AM, <Valdis.Kletnieks@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
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@gmail.com> wrote:
On Mon, Dec 8, 2014 at 10:32 AM, <Valdis.Kletnieks@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@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
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@gmail.com <mailto:xerofoify@gmail.com>> wrote:
On Mon, Dec 8, 2014 at 10:32 AM, <Valdis.Kletnieks@vt.edu <mailto:Valdis.Kletnieks@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@kernelnewbies.org <mailto:Kernelnewbies@kernelnewbies.org> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@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
On Tue, Dec 9, 2014 at 1:26 PM, Philipp Muhoray <philipp.muhoray@gmail.com> wrote:
Am 2014-12-09 um 07:50 schrieb Avinash Patil:
Hi Nick,
<snip>
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).
yes, we all have sent awful patches at some point of time , but on pointed out the mistakes in the patch , we have corrected them and, i suppose, almost all of us have taken care not to repeat that same mistakes again. But its not the case with Nick. You can search the old threads , in lkml , also here .. he has just continued with his way, without caring what has been told to him. If my opinion is counted, I will say NO. thanks sudip
br, phil
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Philipp Muhoray <philipp.muhoray@gmail.com> writes:
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.
It's not a ban, it's a protective filter. Maintainers and reviewers are limited resources. We should not waste them.
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).
If you look at what actually happened, you'll see a very good example of why the filter is still required: The original patch was yet another completely pointless fixme-comment deletion, without any real explanation whatsoever in the commit message. And it wasn't even properly formatted with a subsystem prefixed subject etc. So the maintainer had to spend time trying to fix up the commit message and figuring out why it was OK to delete those fixme comments. As has been pointed out here, that explanation could still be incomplete. I guess the maintainer didn't want to spend hours looking at something as pointless as this. The problem is that he didn't realize that this patch was a waste of time before spending time on it at all. Which is exactly why the maintainers should be protected against having to look at stuff like this, if possible. And in this case it *is*. There are exactly zero examples of valuable patches from that author. If you look at the history of accepted patches, you will find that in each and every case there is some reviewer or maintainer doing the *real* work - figuring out that the patch is OK and explaining why. And the result is still patches without any real value. They don't solve any problem for anyone. They are the result of stupid and mindless grepping for a specific word in comments. Yes, we have all wasted time for maintainers and reviewers by sending them stuff we shouldn't have. That's part of the game. The problem in this case is the massive distribution over an insane number of subsystems in combination with the inability to learn anything at all. Wasting one maintainer's time once is excusable. Wasting hundreds of maintainer's time over and over again is absolutely not. It's potentionally destructive to the whole project if it is allowed to continue. This very thread is yet another example of the contentless noise from this source, and I hate myself for having wasted your time having to read this. Sorry about that. But I write it in the hope that you will understand that the filtering is *not* about punishing anyone. It is about protecting or most valuable resources. And if anyone still wonders: Requests for "ban removal" has no value to the community, and are therefore the exact opposite of what's required to have the filter removed. Bjørn
Bjorn, I understand that now after reading your message. To be honest, I started out like this because I had no idea, where to start. If your willing to give me a place to start, that is of use I will be glad to help out. Over time, I hope we can work this out. Nick On 2014-12-09 04:24 AM, Bjørn Mork wrote:
Philipp Muhoray <philipp.muhoray@gmail.com> writes:
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.
It's not a ban, it's a protective filter. Maintainers and reviewers are limited resources. We should not waste them.
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).
If you look at what actually happened, you'll see a very good example of why the filter is still required: The original patch was yet another completely pointless fixme-comment deletion, without any real explanation whatsoever in the commit message. And it wasn't even properly formatted with a subsystem prefixed subject etc. So the maintainer had to spend time trying to fix up the commit message and figuring out why it was OK to delete those fixme comments. As has been pointed out here, that explanation could still be incomplete. I guess the maintainer didn't want to spend hours looking at something as pointless as this. The problem is that he didn't realize that this patch was a waste of time before spending time on it at all.
Which is exactly why the maintainers should be protected against having to look at stuff like this, if possible. And in this case it *is*. There are exactly zero examples of valuable patches from that author. If you look at the history of accepted patches, you will find that in each and every case there is some reviewer or maintainer doing the *real* work - figuring out that the patch is OK and explaining why. And the result is still patches without any real value. They don't solve any problem for anyone. They are the result of stupid and mindless grepping for a specific word in comments.
Yes, we have all wasted time for maintainers and reviewers by sending them stuff we shouldn't have. That's part of the game. The problem in this case is the massive distribution over an insane number of subsystems in combination with the inability to learn anything at all. Wasting one maintainer's time once is excusable. Wasting hundreds of maintainer's time over and over again is absolutely not. It's potentionally destructive to the whole project if it is allowed to continue.
This very thread is yet another example of the contentless noise from this source, and I hate myself for having wasted your time having to read this. Sorry about that.
But I write it in the hope that you will understand that the filtering is *not* about punishing anyone. It is about protecting or most valuable resources.
And if anyone still wonders: Requests for "ban removal" has no value to the community, and are therefore the exact opposite of what's required to have the filter removed.
Bjørn
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Tue, 09 Dec 2014 06:33:07 -0500, nick said:
I understand that now after reading your message.
Sorry Nick. You might believe that, but nobody else does at this point. We've heard that over and over for the last six months, and then you follow up with behavior that indisputably proves that you either *didn't* understand, or you totally didn't care.
To be honest, I started out like this because I had no idea, where to start. If your willing to give me a place to start, that is of use I will be glad to help out.
I think that given your history, the best service you could do the Linux community is to go work for a competitor. The BSD's and Microsoft are always looking for help. Seriously Nick - whatever your motivations may be, Bjørn is totally right. Overall, you're a negative asset - I've personally submitted patches that you've been trying to get submitted, *just so I didn't have to keep seeing incorrect attempts*. Now, FSM knows that there's been *tons* of times over the past decade that I've spend 5, 10, even 20 times longer talking a newcomer through getting a first patch accepted than it would have taken me to just whomp one out myself and submit it. The difference is that in those cases I had a reasonable expectation that it would be a long-term win. Let's face it Nick - there is no such expectation when you're concerned. Avinash added the story of your most recent waste of Rafal's time. At this point, I really see zero reason for anybody to remove your ban until such time as you've demonstrated a long term (as in several years) ability to do correct and productive development for some other project. Because quite frankly, until you fix whatever your problem is and become productive on your own, we get less done while you're here than if you weren't. And it's not our job to fix your problem. It's your job.
participants (7)
-
Avinash Patil -
Bjørn Mork -
nick -
Nick Krause
-
Philipp Muhoray -
Sudip Mukherjee -
Valdis.Kletnieks＠vt.edu