Remove Ban?

Remove Ban?

[nick]

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

Remove Ban?

[Valdis.Kletnieks at vt.edu]

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....
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20141208/56bc58cc/attachment.bin 

Remove Ban?

[Nick Krause]

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

Remove Ban?

[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> 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 at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20141209/d26bf75f/attachment.html 

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@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 at kernelnewbies.org
>     <mailto:Kernelnewbies@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 

Remove Ban?

[Sudip Mukherjee]

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 at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>

Filtering noise is about protecting resourses (was: Re: Remove Ban?)

[Bjørn Mork]

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

Filtering noise is about protecting resourses

[nick]

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 at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> 

Filtering noise is about protecting resourses

[Valdis.Kletnieks at vt.edu]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20141209/5e1cb0d7/attachment.bin