git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Should git-remote-hg/bzr be part of the core?

From
Michael Haggerty <mhagger@alum.mit.edu>
Date
May 12, 2014, 09:42 UTC
Message-ID
<53709788.2050201@alum.mit.edu>
In-Reply-To
<537008f06ceb8_8e47492f89f@nysa.notmuch>
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.

Show 5 quoted lines
> 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/
Previous: Felipe ContrerasNext: Dennis Kaarsemaker
Message 2 of 19 in “Should git-remote-hg/bzr be part of the core?”
  1. Felipe ContrerasMay 11, 2014
  2. Michael HaggertyMay 12, 2014
  3. Dennis KaarsemakerMay 12, 2014
  4. Felipe ContrerasMay 12, 2014
  5. Michael HaggertyMay 12, 2014
  6. Felipe ContrerasMay 12, 2014
  7. David KastrupMay 12, 2014
  8. Felipe ContrerasMay 12, 2014
  9. Michael HaggertyMay 12, 2014
  10. Felipe ContrerasMay 12, 2014
  11. David KastrupMay 12, 2014
  12. Felipe ContrerasMay 12, 2014
  13. Felipe ContrerasMay 12, 2014
  14. Stefan BellerMay 12, 2014
  15. Felipe ContrerasMay 12, 2014
  16. Felipe ContrerasMay 12, 2014
  17. Paolo CiarrocchiMay 12, 2014
  18. Stefan BellerMay 12, 2014
  19. Felipe ContrerasMay 12, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.