archive mirror
 help / color / mirror / Atom feed
From: Theodore Ts'o <>
To: Felipe Contreras <>
Cc: Max Horn <>, Junio C Hamano <>,
Subject: Re: My patches
Date: Fri, 18 Oct 2013 11:30:09 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <52611e75bdc8d_2b6dcb7e7459@nysa.notmuch>

On Fri, Oct 18, 2013 at 06:41:41AM -0500, Felipe Contreras wrote:
> > And I hazard to guess that the vast majority agree with Junio on this (based,
> > again, on email evidence). Not with you.
> That is irrelevant, and a fallacy. The vast majority of people thought the
> Earth was the center of the universe, and they were all wrong.
> It's called ad populum fallacy, look it up. Wether the majority of Git
> developers agree that there's something more than a disagreement is irrelevant,
> their opinion doesn't change the truth.

Look, the problem is that you insist on being "right", even on matters
which may be more about taste and preference than anything that can be
proven mathematically.  Worse, you insist on trying to convince people
even when it might be better to just give up and decide that maybe
something not's worth the effort to get the last word in.  This is how
we get to centithreads.  If every time someone disagrees, you insist
on replying, and then if people give up in disgust, you then try to
use that as "proof" that you must be right, since you've dazzled them
with your brilliance, that's not good for the development community.

Sometimes a question is important enough that it's worth doing this.
But I'd suggest to you that you should ask yourself whether you're
doing it too often.

After all, this is open source.  If you are convinced that you are
right, and everyone else in the community is wrong, it is within your
power to fork the code base, and to prove us wrong by creating a
better product.

Or you can decide to just keep a patch set to yourself, or perhaps
post it periodically, if it is some key feature that you are certain
you or your company can't live with out.  Heck, I've done this with
ext4, even though I'm the maintainer --- there have been features that
I know are critical for my company, but the rest of the ext4
development community are stridently against.  I've just simply posted
the patch set once, and if it gets strongly opposed, I'll just keep it
as a out-of-tree patch.

The fallocate NO_HIDE_STALE flag is a good example of that; it's used
in production on thousands and thousands of servers by Google and Tao
Bao, but since there was strong opposition on the ext4 list, we've
kept it as an out-of-tree patch.  Note what I did not do.  I did not
force the patch in, even though it might be within my power as the
maintainer; nor did I try to convince people over and OVER and OVER
again about the rightness of my position, and turn it into a

> My claim is that all I did was disagree with Junio. You can invalidate that
> claim easily by providing *a single* example where I did more than disagree.

The problem is when you disagree with a number of people (not just
Junio), and you are, in my opinion, overly persistent.  We can argue
whether you've stepped over the line in terms of impugning people's
motives or sanity, but that's not necessarily the most important
issue.  People sometimes step over the line, and while that's
unfortunate, it's when it becomes a persistent pattern, and it happens
frequently enough, that it becomes a real problem.

Alternatively, if you are right that Junio is mad, and he's being
capriciously insulting, then I'm sure that when you establish your own
fork, lots of developers will come flocking to your flag.  If they do
not, then perhaps you might want to take that as some objective
evidence that the community is perhaps, more willing to work with him,
then they are to work with you.

Best regards,

						- Ted

P.S.  There are plenty of things that I consider to be unfortunate
about git's command line interface, in terms of inconsistencies and
confusing terminology.  Over the past 5+ years, I've observed that I
think the way commit selection in "git format-patch" is inconsistent
with how we handle commit selection for other commands, e.g., "git log
<commit>" vs and "git format-patch <commit>".  Even if you think that
this is a matter of self-inherent "truth", versus just a matter of
taste, there is also the consideration of backwards compatibility, and
the question of how important consistency and easy of learning gets
traded off against backwards compatibility and invalidating
potentially huge numbers of shell scripts and documentation.  So it's
not something where I've made a nuisance of myself, because it's a
settled issue.

As another example, people have agreed for a long time that the fact
that tab characters are significant in Makefiles is highly
unfortunate.  However, no one is running around calling the GNU Make
maintainers "insane" for not being willing to make a change that would
break huge numbers of Makefiles in the world.  More importantly,
people aren't brining up the same subject over and over and over again
on the GNU Makefile mailing list.  Perhaps you might consider what
would be the appropriate response if someone insisteted on creating
centithreads on the GNU Makefile discuss list on that subject.

  reply	other threads:[~2013-10-18 15:30 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-12  7:24 My patches Felipe Contreras
2013-10-12 16:18 ` Philip Oakley
2013-10-12 22:33   ` Felipe Contreras
2013-10-14 17:42 ` Junio C Hamano
2013-10-14 21:40   ` Felipe Contreras
2013-10-17 19:54     ` Junio C Hamano
2013-10-17 21:44       ` Felipe Contreras
2013-10-18 11:21         ` Max Horn
2013-10-18 11:41           ` Felipe Contreras
2013-10-18 15:30             ` Theodore Ts'o [this message]
2013-10-18 15:49               ` Felipe Contreras
2013-10-18 16:59               ` Junio C Hamano

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:

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

  git send-email \ \ \ \ \ \ \

* 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).