On 05/12/2014 12:37 PM, Felipe Contreras wrote:

Michael Haggerty wrote:

quoted

On 05/12/2014 01:34 AM, Felipe Contreras wrote:

quoted

Recently Junio said he was willing to hear the opinion of other people
regarding the move from contrib to the core[1]. This move is already
under way, but suddenly Junio changed his mind.

I agree with Junio.  There are good technical arguments for and against
moving git-remote-hg out of contrib.

Saying you agree with Junio is content-free. You have to say *why* you
agree.

Actually, I don't have to, not even if you tell me to.  And anyway, I
think the small technical advantages/disadvantages of the possible
different locations for git-remote-hg are dwarfed by the social
considerations so I think dwelling on technical considerations would
sidetrack this discussion.

[...]

quoted

1. That subproject has not been maintained to the standards of the Git
project;

The quality of the subjproject has not been called into question, stop
taiting the discussion with red herrings.

On the contrary.  I just called the quality of the subproject into
question, and I stated exactly which aspects of its quality I find to be
inadequate in the text that you omitted from your response:

[...] specifically, Git project standards include good commit
messages and a willingness to engage with the community on a friendly
and constructive way and to welcome feedback.  Because of your
confrontational and nit-picking style, Felipe, many people who have
tried to help you improve your work are rebuffed and end up giving up
out of frustration or exhaustion.  Because of this, your commits do not
benefit from the usual amount of help from the community and therefore
their quality is not as high as required for commits to core Git.

Commit quality very definitely includes the quality of log messages and
the quality of the discussion on the mailing list that can inform people
working on those areas of the code in the future.

quoted

2. Moving git-remote-hg into the core would require even *more* of your
presence on the Git mailing list.

That's not true. I sent my patches at my own pace, it doesn't matter if
they are in contrib or in the core, I would have kept sending them at
the same pace. I have addressed all issues and responded to all
questions as if they were already part of the core, which is why they
have more quality than other tools already in the core. I only stopped
doing that when Junio changed the direction we had since day one.

Also a red herring.

OK, maybe you are technically correct there.  There is indeed a
difference between > and >=.  Let me amend my claim:

2. Moving git-remote-hg into the core would require you to continue your
   presence on the Git mailing list.

quoted

quoted

[...] Does it make sense to you that
you get thrown in jail for a crime you haven't committed merely because
someone thinks it's likely you will?

Being the leader of your own valuable open-source project is nothing
like jail.  It is an opportunity for you to shine in an environment that
is more suited to your personality.

Don't be ridiculous. There is no out-of-tree tool that could possibly
compete in popularity against core tools.

I never made that claim.  I claimed that it was "nothing like jail", and
I stand by that claim.  I also think that the Git community is a place
unsuited to someone with your personality, and that you might truly
shine more in an independent project.

If you think being out-of-tree is not a negative, lets throw out
git-archimport, git-quiltimport, git-p4, git-cvs, git-svn. Let us give
them an "opportunity to shine".

In my opinion, the technical issues for moving importers are not
overwhelming.  Therefore, I don't have a strong opinion about the future
of these other tools, because their presence in the Git tree is not
coupled to the continued presence of a problematic subproject maintainer.

You know that those tools do better in the core, and you know
git-remote-hg/bzr would do better in the core. Don't act as if you
didn't.

I maintain cvs2svn/cvs2git outside of the Git core.  In fact, one of
cvs2git's competitors, "git cvsimport" *is* in Git core.  Nevertheless,
users have no problem finding cvs2git, and I think it's safe to say that
its reputation exceeds that of "git cvsimport", even though some people
accidentally use "git cvsimport" out of laziness.

People who need to do a conversion from A to B only have to Google for
"A B" and they will find the best conversion tools pretty easily.  If
the tools are packaged for their OS then they are just an "apt-get
install" away from happiness.  And given that tools like cvs2git or
git-remote-hg, don't even need to be compiled, users can install them
pretty easily themselves.

quoted

This email is written in sorrow, not in anger.  Felipe, you seem to have
so much potential.  If you would put as much effort in conducting social
interactions as you do in coding, the whole balance would change
entirely, and any software project would be happy to have you.  With all
my heart I truly wish you the best in your future endeavors.

Let's see how sincere you are in your sentiment. I'll reply to you
personally about the points that I consider to be red herrings and ad
hominem attacks so we don't taint the dicussion. If you don't reply I'll
know you were not being sincere.

Jumping at your every demand is not a prerequisite for being sincere.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/