From: Felipe Contreras <felipe.contreras@gmail.com>
To: Ramkumar Ramachandra <artagnon@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
git@vger.kernel.org, Christophe Simonis <christophe@kn.gl>,
Simon Ruderich <simon@ruderich.org>, Max Horn <max@quendi.de>
Subject: Re: [PATCH 1/9] remote-bzr: trivial cleanups
Date: Fri, 26 Apr 2013 15:00:11 -0500 [thread overview]
Message-ID: <CAMP44s1RTm3LRaL71U1LQ=RvA1qyOSQKsk1ptXeNP-GRk3rVrw@mail.gmail.com> (raw)
In-Reply-To: <CALkWK0=J2_mAViDwu2MJNvLsUbVpoR68-sQR9fs=4of+E5wAjg@mail.gmail.com>
On Fri, Apr 26, 2013 at 2:30 PM, Ramkumar Ramachandra
<artagnon@gmail.com> wrote:
> [completely off-topic; don't worry, we're just having a friendly chat]
>
> Felipe Contreras wrote:
>> If you are not prepared to defend your review, so are others, why to
>> you blame that on me? If you were right, you would be shown to be
>> right. Period.
>
> Felipe, there are some things that are worth arguing about for a long
> time (like the new revision spec I'm proposing in [1]), and others
> that are not.
>
> [1]: http://thread.gmane.org/gmane.comp.version-control.git/222248/focus=222526
I agree, and I have discussed about issues with diff in the past,
unfortunately didn't reach any conclusion. I've tried to follow that
thread, but I don't really know what is actually being proposed
anymore.
If you are so keen in receiving feedback from your fellow developers,
you should eventually send an email summarizing the issues and the
proposal for everyone to understand.
In contrast, I take it you agree this trivial patch is not worth
discussing, which I agreed in my first reply.
>> No, we operate in evidence and reason, *not* opinion. Any reasonable
>> person would say "well, I *think* this commit message needs more
>> description, but I don't *know*, I don't have *evidence* for it, so
>> I'm not going to fight to the death, as if I had".
>
> Don't you think you're taking reason to an extreme here? Reason is a
> tool that I use when I want. I don't want reason when I'm browsing
> Google Art Project or listening to Gentle Giant. Arguments like "is
> this commit message large enough?" are really not worth the time and
> effort.
Reason is not a tool for appreciating art, reason is a tool for
discovering truth, and if when arguing you are not interested in what
is actually true, I'm not interested in arguing with you.
>> Ultimately the decision to merge or not to merge comes to Junio, if
>> you don't like his decision, go complain to him, but I would be
>> prepared with points in time where people complained about these
>> patches, and there are no complains, so you have no ammunition at all
>> whatsoever.
>
> I have no desire to "attack" you, Felipe. I respect you as a more
> experienced developer than myself, and am trying to offer constructive
> criticism.
>
> I don't have an ego (or consider myself important to the community).
> Whatever will happen will happen, with or without me.
I appreciate your criticism, but that doesn't mean I must agree with
it. And if I do agree, that doesn't mean I must act upon it.
>> And this is how communities die. When everybody thinks the same, and
>> everyone who thinks differently is displaced. A monoculture, a place
>> full of yes-men where nobody criticizes anybody, a circlejerk where
>> everyone palms the back of everyone else. Eventually things go south,
>> and nobody around you understands why.
>>
>> Diversity in a community is healthy. If you don't like people who
>> think differently, *you* have a problem. If you don't like standing up
>> and defending your ideas, *you* have a problem. If you don't like
>> discussing on the basis of evidence and reason, *you* have a problem.
>
> Diversity is certainly healthy, and I it would be nice to have you in
> the community. We just have to find a way to keep the conflict down.
A fine way to start is to not rattle away in trivial inconsequential patches.
Cheers.
--
Felipe Contreras
next prev parent reply other threads:[~2013-04-26 20:00 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-25 11:20 [PATCH 0/9] remote-helpers: fixes and cleanups Felipe Contreras
2013-04-25 11:20 ` [PATCH 1/9] remote-bzr: trivial cleanups Felipe Contreras
2013-04-25 18:19 ` Ramkumar Ramachandra
2013-04-25 19:20 ` Felipe Contreras
2013-04-25 20:30 ` Thomas Rast
2013-04-25 20:52 ` Felipe Contreras
2013-04-25 21:37 ` Junio C Hamano
2013-04-25 21:49 ` Felipe Contreras
2013-04-25 20:36 ` Junio C Hamano
2013-04-25 21:35 ` Felipe Contreras
2013-04-25 22:01 ` Junio C Hamano
2013-04-25 22:58 ` Felipe Contreras
2013-04-25 23:11 ` Junio C Hamano
2013-04-26 1:19 ` Felipe Contreras
2013-04-26 12:19 ` Ramkumar Ramachandra
2013-04-26 18:48 ` Felipe Contreras
2013-04-26 18:53 ` Ramkumar Ramachandra
2013-04-26 19:39 ` Felipe Contreras
2013-04-26 19:56 ` Ramkumar Ramachandra
2013-04-26 20:23 ` Felipe Contreras
2013-04-26 22:10 ` Junio C Hamano
2013-04-26 22:22 ` Felipe Contreras
2013-04-26 19:39 ` Ramkumar Ramachandra
2013-04-26 9:32 ` Ramkumar Ramachandra
2013-04-26 18:34 ` Felipe Contreras
2013-04-26 19:30 ` Ramkumar Ramachandra
2013-04-26 19:59 ` Ramkumar Ramachandra
2013-04-26 20:00 ` Felipe Contreras [this message]
2013-04-26 20:03 ` Ramkumar Ramachandra
2013-04-26 20:28 ` Felipe Contreras
2013-04-26 20:28 ` Ramkumar Ramachandra
2013-04-26 20:46 ` Felipe Contreras
2013-04-26 19:19 ` Felipe Contreras
2013-04-26 20:17 ` Ramkumar Ramachandra
2013-04-26 21:00 ` Felipe Contreras
2013-04-25 19:29 ` Stefano Lattarini
2013-04-25 19:33 ` Felipe Contreras
2013-04-25 11:20 ` [PATCH 2/9] remote-hg: remove extra check Felipe Contreras
2013-04-25 18:23 ` Ramkumar Ramachandra
2013-04-25 19:22 ` Felipe Contreras
2013-04-25 11:20 ` [PATCH 3/9] remote-bzr: fix bad state issue Felipe Contreras
2013-04-25 11:20 ` [PATCH 4/9] remote-bzr: add support to push URLs Felipe Contreras
2013-04-25 11:20 ` [PATCH 5/9] remote-hg: use hashlib instead of hg sha1 util Felipe Contreras
2013-04-25 18:25 ` Ramkumar Ramachandra
2013-04-25 19:30 ` Felipe Contreras
2013-04-25 11:20 ` [PATCH 6/9] remote-bzr: store converted URL Felipe Contreras
2013-04-25 11:20 ` [PATCH 7/9] remote-hg: use python urlparse Felipe Contreras
2013-04-25 11:20 ` [PATCH 8/9] remote-bzr: tell bazaar to be quiet Felipe Contreras
2013-04-25 11:20 ` [PATCH 9/9] remote-bzr: strip extra newline Felipe Contreras
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='CAMP44s1RTm3LRaL71U1LQ=RvA1qyOSQKsk1ptXeNP-GRk3rVrw@mail.gmail.com' \
--to=felipe.contreras@gmail.com \
--cc=artagnon@gmail.com \
--cc=christophe@kn.gl \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=max@quendi.de \
--cc=simon@ruderich.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).