From: Felipe Contreras <hidden> Date: 2016-06-15 23:01:06
Hi,
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 have repeatedly asked him to clarify what argument changed his mind,
but he hasn't done so. Hopefully he will do that in this thread, but
I'll jump ahead and assume it's this one by John Keeping[2]:
I do not want to end up in a situation where an update to Git is
blocked by a distribution because git-remote-hg is not updated to
support newer versions of Mercurial sufficiently quickly; this
previously happened in Gentoo due to git-svn and meant that was stuck
on 1.7.8 until 1.7.13 was released [X].
Now, I feel I addressed this argument at length, specially in this
thread [3], but I'll try to provide a summary of the strongest arguments
against:
1) We can make the tests optional, say 't/optional'. So if they don't
pass, the build of Git is not broken. Additionally, distributions
might prefer to run test-essential if they don't want to run these
optional tests.
2) There's already continuous integration builds[4] to make sure all
the possible incoming changes in Mercurial are detected early on.
3) There has been a *single* case where a new Mercurial (3.0) broke
things. This is due to the fact of how I implemented certain
functionality due to limitations in Mercurial's API. Mercurial
authors can be contacted to improve the API and minimize the
possibility of it happening again.
Given these arguments, I don't see how moving git-remote-hg to the core
could possibly cause any problems, and I don't understand why Junio
would think otherwise. Even if such a breakage causes a problem to the
whole Git, it would make sense to demote these tools *when* such a
problem comes (which I argue it won't). 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?
Given the huge amount of work I've put in these remote helpers, and the
fact that Junio said since day 1 he wanted these in the core[5] (and I
was operating under that assumption), I think the demotion back to the
contrib area (and therefore out-of-tree) should be made carefully, and
not from one day to he next as it happened.
Thoughts?
[1] http://article.gmane.org/gmane.comp.version-control.git/248676
[2] http://article.gmane.org/gmane.comp.version-control.git/248167
[3] http://article.gmane.org/gmane.comp.version-control.git/248683
[4] https://travis-ci.org/felipec/git
[5] http://article.gmane.org/gmane.comp.version-control.git/220277
--
Felipe Contreras
From: Michael Haggerty <hidden> Date: 2016-06-15 23:01:06
On 05/12/2014 01:34 AM, Felipe Contreras wrote:
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. Those arguments were discussed at
length and I think their weight is on the side of not moving it. But
there are two other (in my opinion, stronger) reasons for keeping
git-remote-hg out of the core:
1. That subproject has not been maintained to the standards of the Git
project; 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.
2. Moving git-remote-hg into the core would require even *more* of your
presence on the Git mailing list. But your very presence is detrimental
to the rest of the community. You insult and frustrate people who are
trying to help you. You attribute malign motivations to people who are
trying to be scrupulously fair. You string out enormous threads of
nit-picking, legalistic argumentativeness that have little to do with
the real issues at hand.
The last big "Felipe eruption" in the summer of 2013 caused an enormous
amount of strife, wasted an inordinate amount of time of other community
members, and caused at least one valued contributor to temporarily
rage-quit the community. That episode only ended when Junio asked you
to leave the community [1], which, thankfully, you did for a while.
After you left, the atmosphere of the mailing list soon returned to its
usual friendly, collegial, and efficient norm.
Recently you returned to the mailing list. In my opinion everybody on
the list, including especially Junio, interacted with you in a very
polite and businesslike manner. I believe you were given an honest
chance at a fresh start in the community. I wish you had taken it. The
Git project could really benefit from the help of a skilled and
energetic developer like you!
But it didn't take long before you started the same theatrics again.
And now again, dealing with your caustic attitude is wasting an order of
magnitude more time of the other core developers than your contributions
could possibly bring in benefits.
For me, the conclusion is unfortunate but clear: Felipe Contreras is (by
far) a net liability to the Git project. Specifically:
* The Git project will progress faster without you because the other
contributors will have to waste less time dealing with your antics.
* The Git community will grow faster without you, because your presence
will not cause existing contributors to withdraw and dissuade new
contributors from joining.
* The community will be a lot more pleasant without you.
Therefore, I am happy that you have apparently decided to split
git-remote-hg into a separate project. I wish you success with the
project and I see no reason that it shouldn't continue to be successful.
But I am glad that I will not have to interact with you anymore.
[...] 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.
Given the huge amount of work I've put in these remote helpers, and the
fact that Junio said since day 1 he wanted these in the core[5] (and I
was operating under that assumption), I think the demotion back to the
contrib area (and therefore out-of-tree) should be made carefully, and
not from one day to he next as it happened.
None of the work was wasted. git-remote-hg can live on.
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.
Michael
[1] http://article.gmane.org/gmane.comp.version-control.git/227750
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
From: Dennis Kaarsemaker <hidden> Date: 2016-06-15 23:01:06
Michael,
Thank you for writing this, I have to see I agree completely. As a
mostly lurker on this list, I tend to skip any thread Felipe is
participating in, as it tends to quickly spiral out of control.
This is also the main reason for me not to actively participate a bit
more, I prefer reasonable discussions over fighting.
On ma, 2014-05-12 at 11:42 +0200, Michael Haggerty wrote:
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. Those arguments were discussed at
length and I think their weight is on the side of not moving it. But
there are two other (in my opinion, stronger) reasons for keeping
git-remote-hg out of the core:
1. That subproject has not been maintained to the standards of the Git
project; 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.
2. Moving git-remote-hg into the core would require even *more* of your
presence on the Git mailing list. But your very presence is detrimental
to the rest of the community. You insult and frustrate people who are
trying to help you. You attribute malign motivations to people who are
trying to be scrupulously fair. You string out enormous threads of
nit-picking, legalistic argumentativeness that have little to do with
the real issues at hand.
The last big "Felipe eruption" in the summer of 2013 caused an enormous
amount of strife, wasted an inordinate amount of time of other community
members, and caused at least one valued contributor to temporarily
rage-quit the community. That episode only ended when Junio asked you
to leave the community [1], which, thankfully, you did for a while.
After you left, the atmosphere of the mailing list soon returned to its
usual friendly, collegial, and efficient norm.
Recently you returned to the mailing list. In my opinion everybody on
the list, including especially Junio, interacted with you in a very
polite and businesslike manner. I believe you were given an honest
chance at a fresh start in the community. I wish you had taken it. The
Git project could really benefit from the help of a skilled and
energetic developer like you!
But it didn't take long before you started the same theatrics again.
And now again, dealing with your caustic attitude is wasting an order of
magnitude more time of the other core developers than your contributions
could possibly bring in benefits.
For me, the conclusion is unfortunate but clear: Felipe Contreras is (by
far) a net liability to the Git project. Specifically:
* The Git project will progress faster without you because the other
contributors will have to waste less time dealing with your antics.
* The Git community will grow faster without you, because your presence
will not cause existing contributors to withdraw and dissuade new
contributors from joining.
* The community will be a lot more pleasant without you.
Therefore, I am happy that you have apparently decided to split
git-remote-hg into a separate project. I wish you success with the
project and I see no reason that it shouldn't continue to be successful.
But I am glad that I will not have to interact with you anymore.
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.
quoted
Given the huge amount of work I've put in these remote helpers, and the
fact that Junio said since day 1 he wanted these in the core[5] (and I
was operating under that assumption), I think the demotion back to the
contrib area (and therefore out-of-tree) should be made carefully, and
not from one day to he next as it happened.
None of the work was wasted. git-remote-hg can live on.
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.
Michael
[1] http://article.gmane.org/gmane.comp.version-control.git/227750
From: Felipe Contreras <hidden> Date: 2016-06-15 23:01:06
Michael Haggerty wrote:
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.
You mention there are good technical arguments against the graduation of
the tools. Surely if you have analyzed those arguments enough to form an
opinion aligned with Junio's, it should be easy to provide a short
summary of those "good technical arguments". Can you do that?
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.
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.
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.
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".
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.
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.
Cheers.
--
Felipe Contreras
From: Michael Haggerty <hidden> Date: 2016-06-15 23:01:06
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/
From: Felipe Contreras <hidden> Date: 2016-06-15 23:01:06
Michael Haggerty wrote:
On 05/12/2014 12:37 PM, Felipe Contreras wrote:
quoted
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,
Then there's no point in reading what else you have to say. Whatever
reasons you might have to agree with Junio are known only to you, thus
your "agreement" is opaque and meaningless.
quoted
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:
I'll wait until somebody else calls into question the quality.
Preferably somebody who backs up his claims with evidence.
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.
That is another red herring. Moving them back to the contrib/ area which
is what Junio proposed would also require my presence on the list. Is
that what you want?
And there's the transport helper, and bash completion, and the zsh
completion.
quoted
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.
In the context of the Git project what is the *worst* thing the
maintainer can do to a piece of code but delete it? So I think you are
right, the jail analogy is not correct; it's *execution*.
quoted
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.
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.
Let's test that hypothesis:
Google: how to conver mercurial to git
* Convert Mercurial project to Git - Stack Overflow (NOPE)
* Converting a Mercurial repository to Git (YEAP: one among many)
Oh, but would you look at that:
This script will actually be shipping with git at some point, which
gives it some credibility in my book.
* frej/fast-export · GitHub (NOPE)
* Hg-Git Mercurial Plugin (NOPE)
* Converting Hg repositories to Git (NOPE)
* Converting from Mercurial to Git - Hivelogic (NOPE)
* Converting Repositories From Git to Mercurial (NOPE)
* hg-fast-export: convert Mercurial repositories (NOPE)
* Converting Mercurial (Hg) to Git Repository on Mac (NOPE)
* Bitbucket: Converting Hg repositories to Git (NOPE)
So pretty much hypoethesis failed. That fact that you would even think
people would quickly find about git-remote-hg shows exactly how detached
you are from the problem.
If the tools are packaged for their OS then they are just an "apt-get
install" away from happiness.
Oh, they are packaged already (as part of Git). Moving them out-of-tree
will make it much more difficult for users to find them, and install
them. It will take time for them to be packaged, if it happens at all.
quoted
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.
I spent a lot of time writing that mail. Not sincere it is then.
--
Felipe Contreras
From: Michael Haggerty <hidden> Date: 2016-06-15 23:01:06
On 05/12/2014 02:29 PM, Felipe Contreras wrote:
Michael Haggerty wrote:
[...]
quoted
2. Moving git-remote-hg into the core would require you to continue your
presence on the Git mailing list.
That is another red herring. Moving them back to the contrib/ area which
is what Junio proposed would also require my presence on the list. Is
that what you want?
No, actually my preference is that git-remote-hg be separated from the
Git project altogether, for the reasons that I stated earlier.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
From: Felipe Contreras <hidden> Date: 2016-06-15 23:01:06
Michael Haggerty wrote:
On 05/12/2014 02:29 PM, Felipe Contreras wrote:
quoted
Michael Haggerty wrote:
[...]
quoted
2. Moving git-remote-hg into the core would require you to continue your
presence on the Git mailing list.
That is another red herring. Moving them back to the contrib/ area which
is what Junio proposed would also require my presence on the list. Is
that what you want?
No, actually my preference is that git-remote-hg be separated from the
Git project altogether, for the reasons that I stated earlier.
Exactly. So your point 2. is completely irrelevant to the contrb/ vs.
core debate.
--
Felipe Contreras