kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
From: bjorn@mork.no (Bjørn Mork)
To: kernelnewbies@lists.kernelnewbies.org
Subject: Filtering noise is about protecting resourses (was: Re: Remove Ban?)
Date: Tue, 09 Dec 2014 10:24:53 +0100	[thread overview]
Message-ID: <87388pch0a.fsf_-_@nemi.mork.no> (raw)
In-Reply-To: <5486AB37.9040008@gmail.com> (Philipp Muhoray's message of "Tue, 09 Dec 2014 08:56:39 +0100")

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

  parent reply	other threads:[~2014-12-09  9:24 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-08  3:15 Remove Ban? nick
2014-12-08 15:32 ` Valdis.Kletnieks at vt.edu
2014-12-08 15:56   ` Nick Krause
2014-12-09  6:50     ` Avinash Patil
2014-12-09  7:56       ` Philipp Muhoray
2014-12-09  8:05         ` Sudip Mukherjee
2014-12-09  9:24         ` Bjørn Mork [this message]
2014-12-09 11:33           ` Filtering noise is about protecting resourses nick
2014-12-09 18:27             ` Valdis.Kletnieks at vt.edu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87388pch0a.fsf_-_@nemi.mork.no \
    --to=bjorn@mork.no \
    --cc=kernelnewbies@lists.kernelnewbies.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).