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

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

[Felipe Contreras]

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

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

[Felipe Contreras]

Linus Torvalds wrote:
> On May 12, 2014 8:35 AM, "Felipe Contreras" <felipe.contreras@gmail.com>
> wrote:
> >
> > This move is already
> > under way, but suddenly Junio changed his mind.
> 
> That "suddenly" wouldn't have anything to do with you being an ass and
> difficult as usual, arguing about everything and just generally being
> contrary?

No, here's where the thread started (A):
http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248167

Here I wasn't being an ass:
http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248186

Here I wasn't being an ass either:
http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248171

Neither here:
http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248146

Nor here:
http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248195

Nor here:
http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248205

Not an ass here:
http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248213

And not here either:
http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248236

Then Junio *suddenly* changed his mind (B):
http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248242

That is the sequence of mails (A..B) where I responded, and I wasn't an
ass in eithe one of those, so whatever made Junio change his mind
happened in that interum, and it wasn't me "being an ass".

I bet you made that statement without even botherting to read the
thread. Go on, read the thread, tell where exactly me "being an ass"
made Junio change his mind from A, to B.

Nah, you wouldn't do that, backing up your claims take time, and you are
not willing to spend time on this issue. Even if you were to try to back
up your claim, you couldn't, becasue it's not true. It's much easier to
just throw good sounding baseless claims and walk away.

> Felipe, stop this stupid blaming of everybody but yourself.

Show me evidence that this decision was my fault. Junio certainly hasn't
said so. You just have no idea what we are talking about.

> You make absolutely everything be this horrible disaster, you redefine
> words ("regression") to be whatever you need/want them to be to be

git-remote-hg and git-remote-bzr will likely break in Git v2.0 in certain
situations where they wouldn't in v1.9, or v1.8. Call it whatever you
want. I call that a regression.

> Seriously. Don't try to make this about Junio somehow being the problem.

So Junio is perfect. Got it.

If you don't have the time to actually read the rationale behind Junio's
decision, how would you even know he made the right one? You are just
blindly assuming he is right, and therefore he is not the problem.

What if he was wrong? Nah, that's impossible. Right?

-- 
Felipe Contreras

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

[Felipe Contreras]

Felipe Contreras wrote:
> Linus Torvalds wrote:
> > Felipe, stop this stupid blaming of everybody but yourself.
> 
> Show me evidence that this decision was my fault. Junio certainly hasn't
> said so. You just have no idea what we are talking about.

Here, let me show you.

Junio, can you answer these questions?

 1) What is missing from git-remote-hg/bzr in order for them to be
    considered to be merged to the core?

 2) If a different maintainer steps up, would you consider reconsider
    merging them to the core?

 3) Is there any chance that in the future you would consider them after
    they are more mature, and/or perhaps with a different maintainer?

Unless Junio changes his mind again, the answers to those questions
should be clear already to the people following the discussion
(i.e. not you).

-- 
Felipe Contreras

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

[Michael Haggerty]

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/

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

[Stefan Beller]

2014-05-12 10:12 GMT+02:00 Felipe Contreras <felipe.contreras@gmail.com>:
> Felipe Contreras wrote:
>> Linus Torvalds wrote:
>> > Felipe, stop this stupid blaming of everybody but yourself.
>>
>> Show me evidence that this decision was my fault. Junio certainly hasn't
>> said so. You just have no idea what we are talking about.
>
> Here, let me show you.
>

I suspect Linus had a reason not to include the mailing lists
in the first place and make a huge public discussion,
but instead wrote to you personally.
I guess this is just Linus desire not to waste the time of everybody
as he learned that these discussions are fruitless sometimes.

Junio C Hamano wrote [in another thread]:
> I would not mind asking the others, as your discussion tactic seems
> to be "repeated voices start sounding like a chorus, and a chorus is
> project concensus".
>
> Those who are observing from the sideline, please raise your hand if
> you think the three-line "Clarification" Felipe gave us is a fair
> and accurate clarification.  Anybody?
>
> I also do not mind seeing hands raised of those who do not agree,
> even though I already know that they would be a silent majority.

I think Junio is behaving very professional unlike you, Felipe.
This includes being polite and very patient.
Also this includes weighting different reasons to make
informed rational decisions.

Git being a project widely used and people trusting it for their
work needs to have high quality and cannot go left today and
go right tomorrow, but most of the decisions are done long-term.

Felipe, this may be the reason, why you think nothing changes.
It's just slower than you'd like, but with more thoughts weighted.

Junio, I think you're doing an awesome job in maintaining Git
and leading the community.

Stefan

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

[Dennis Kaarsemaker]

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:
> > 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
> 

-- 
Dennis Kaarsemaker
http://www.kaarsemaker.net

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

[Felipe Contreras]

Michael Haggerty wrote:
> 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.

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.

> > [...] 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

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

[David Kastrup]

Michael Haggerty <mhagger@alum.mit.edu> writes:

> 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, [...]

I think that's where you are mistaken.  We are not talking about a lack
of effort here.  It is just not spent conducively.

-- 
David Kastrup

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

[Felipe Contreras]

Stefan Beller wrote:
> 2014-05-12 10:12 GMT+02:00 Felipe Contreras <felipe.contreras@gmail.com>:
> > Felipe Contreras wrote:
> >> Linus Torvalds wrote:
> >> > Felipe, stop this stupid blaming of everybody but yourself.
> >>
> >> Show me evidence that this decision was my fault. Junio certainly hasn't
> >> said so. You just have no idea what we are talking about.
> >
> > Here, let me show you.
> 
> I suspect Linus had a reason not to include the mailing lists
> in the first place

Huh?

He did include the mailing lists in the first place[1]. Either something
is wrong with the mailing list, or somebody is removing the mails.

You can see the full thread in the git-fc mailing list, and there you
can see the git ml is included in all the mails, including the one you
just sent, where you included the git ml, and it doesn't show in the
archives.

> and make a huge public discussion, but instead wrote to you
> personally.  I guess this is just Linus desire not to waste the time
> of everybody as he learned that these discussions are fruitless
> sometimes.

Don't you agree that including transparent bridges for Mercurial and
Bazaar distributed by default would be benefitial to the project?

If a discussion could potentially lead to them being included, I'd say
that wouldn't be fruitless, but it's *precisely* what our end users
would like us to be discussing right now.

> Junio C Hamano wrote [in another thread]:
> > I would not mind asking the others, as your discussion tactic seems
> > to be "repeated voices start sounding like a chorus, and a chorus is
> > project concensus".
> >
> > Those who are observing from the sideline, please raise your hand if
> > you think the three-line "Clarification" Felipe gave us is a fair
> > and accurate clarification.  Anybody?
> >
> > I also do not mind seeing hands raised of those who do not agree,
> > even though I already know that they would be a silent majority.
> 
> I think Junio is behaving very professional unlike you, Felipe.
> This includes being polite and very patient.

> Also this includes weighting different reasons to make
> informed rational decisions.

Where is he weighting the different reasons? I've asked him multiple
times to provide those reasons. He mensions there's one, but he doesn't
say which one it is.

If I haven't see this reason, how do you know he is weighing different
ones?

> Git being a project widely used and people trusting it for their
> work needs to have high quality and cannot go left today and
> go right tomorrow, but most of the decisions are done long-term.

Yes. What is right, and what is left in this example?

Presumably going right would be to include these tools in the core, but
that would imply that he plans to go left in the future. But he hasn't
said that. So what makes you think the project would go "left" in the
future?

> Felipe, this may be the reason, why you think nothing changes.
> It's just slower than you'd like, but with more thoughts weighted.

Really? I'll issue the same challenge I've issued to many people.

Name a single important change in Git (was one way before, it's another
way now) that has happened in the last 5 years. And by important I mean
for starters users noticed it.

You won't be able to, because nothing ever changes.

> Junio, I think you're doing an awesome job in maintaining Git
> and leading the community.

Maintaining, yes, but leading? Leading it where?

[1] https://groups.google.com/forum/#!original/git-fc/Clhss-fXS2k/9UtiilJ2WQ4J

-- 
Felipe Contreras

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

[Michael Haggerty]

On 05/12/2014 12:37 PM, Felipe Contreras wrote:
> Michael Haggerty wrote:
>> 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.
> 
> 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.

> [...]
> 
>> 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.

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

>>> [...] 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.

>> 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/

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

[Felipe Contreras]

Michael Haggerty wrote:
> On 05/12/2014 12:37 PM, Felipe Contreras wrote:
> > Michael Haggerty wrote:
> >> 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.
> > 
> > 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.

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

> >>> [...] 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*.

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

> > 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

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

[Felipe Contreras]

Paolo Ciarrocchi wrote:
> On Mon, May 12, 2014 at 11:42 AM, Michael Haggerty <mhagger@alum.mit.edu>wrote:
> 
> > 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.
> 
> I really *love* this paragraph. Felipe, you are a brilliant developer
> and you put a lot of work trying to improve GIT.

Thanks.

> While I agree with you the this project is managed in a bit conservative
> way

Only a bit? I don't think I've been involed in a more conservative open
source project.

> you should really improve how you communicate with other developers,
> it's such a pity your contributions are some times not included in
> git.git just because of your attitude.

But that's a theory. You don't *know* that they would have been included
had I used a different attitude.

In fact, people have contacted me privately saying similar things, and
I'll give you the same challenge I gave them. If you think a different
attitude would get my patches in, how about *you* write the commit
messages and the discussions for one of my stuck patch series. I'll send
the mails as if I had written the content.

If you are right, the different attitude would make the patches land in
no time. I still think it's not right for patches to be rejected simply
because of attitude, but I would accept you were right.

But I think you already know that won't happen, the patches still won't
get in, not because of the attitude, but because of what they are trying
to do: change things.

So if I *know* certain feature would be useful for Git users, I've
listened to all the comments, and addressed all the problems, why would
I give up on those patches? Why would I work on something more boring
that won't benefit users as much but would have higher chances of
getting in?

I'm doing this on my own free time, I can choose to do whatever I want,
in whatever way I want, so no, I'll keep working on what I think is
important.

If you really think the patches can be accepted with a different
attitude, by all means, let's do the experiment and find out.

-- 
Felipe Contreras

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

[David Kastrup]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> Michael Haggerty wrote:
>> On 05/12/2014 12:37 PM, Felipe Contreras wrote:
>> > Michael Haggerty wrote:
>> >> 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.
>> > 
>> > 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.

Let me spell it out for you.  Michael states "I agree with Junio.  There
are good technical arguments for and against moving git-remote-hg out of
contrib."  Since there are arguments for both sides, the decision boils
down to a judgment call.  Michael states that he condones the choice
Junio made, based on the reasoning he gave.

Does that mean that he examined the choice with equal detail and
remembers every detail?  No.  In such a decision, both technical
expertise as well as trust based on a past record factor in.

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

The evidence for the toxicity of dealing with subprojects maintained by
you is all over the mailing list.

You are obviously blind to it yourself.  Feel free to print out a few
salient threads where you argue in favor of your points and ask someone
you trust about his impression about how you come across.

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

That kind of exchange is what you should show some of your personal
friends and ask them whether it will likely lead to the desired
understanding and ultimately reaction in the reader.

Because that is what communication is about.  Of course, one can try
bypassing understanding and directly aim for a particular reaction: that
is being manipulative.  You are hardly in danger of being manipulative:
that would require a basic understanding of people.  So all you can
really aim for is understanding: presenting your best case.  Forget
about "rhetorics" and the like: you suck at them, and a technical
audience is easily annoyed by them even when they are employed well.

And if a calm presentation does not lead others to the same conclusion
that you would draw, deal with the consequences.  Throwing tantrums will
only bias people against you when you have the next case to present.

-- 
David Kastrup

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

[Michael Haggerty]

On 05/12/2014 02:29 PM, Felipe Contreras wrote:
> Michael Haggerty wrote:
> [...]
>> 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/

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

[Paolo Ciarrocchi]

On Mon, May 12, 2014 at 2:48 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
>
> Paolo Ciarrocchi wrote:
> > On Mon, May 12, 2014 at 11:42 AM, Michael Haggerty <mhagger@alum.mit.edu>wrote:
> >

> > While I agree with you the this project is managed in a bit conservative
> > way
>
> Only a bit? I don't think I've been involed in a more conservative open
> source project.
>
> > you should really improve how you communicate with other developers,
> > it's such a pity your contributions are some times not included in
> > git.git just because of your attitude.
>
> But that's a theory. You don't *know* that they would have been included
> had I used a different attitude.

Well, you could at least try to act and communicate differently.

> In fact, people have contacted me privately saying similar things, and
> I'll give you the same challenge I gave them. If you think a different
> attitude would get my patches in, how about *you* write the commit
> messages and the discussions for one of my stuck patch series. I'll send
> the mails as if I had written the content.

No, sorry but I'm NOT interested in lying to git community.

Ciao,
-- 
Paolo

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

[Stefan Beller]

2014-05-12 15:45 GMT+02:00 Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>:

>
> No, sorry but I'm NOT interested in lying to git community.
>

It's not lying. See the "Helped-By: <>" lines in git.git commits.
Often the help was formulating a correct and easy-to-understand
commit message.

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

[Felipe Contreras]

Paolo Ciarrocchi wrote:
> On Mon, May 12, 2014 at 2:48 PM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
> > Paolo Ciarrocchi wrote:
> > > On Mon, May 12, 2014 at 11:42 AM, Michael Haggerty <mhagger@alum.mit.edu>wrote:
> 
> > > While I agree with you the this project is managed in a bit conservative
> > > way
> >
> > Only a bit? I don't think I've been involed in a more conservative open
> > source project.
> >
> > > you should really improve how you communicate with other developers,
> > > it's such a pity your contributions are some times not included in
> > > git.git just because of your attitude.
> >
> > But that's a theory. You don't *know* that they would have been included
> > had I used a different attitude.
> 
> Well, you could at least try to act and communicate differently.

I have, it doesn't make a difference.

> > In fact, people have contacted me privately saying similar things, and
> > I'll give you the same challenge I gave them. If you think a different
> > attitude would get my patches in, how about *you* write the commit
> > messages and the discussions for one of my stuck patch series. I'll send
> > the mails as if I had written the content.
> 
> No, sorry but I'm NOT interested in lying to git community.

Yeah, that's what I thought. I know what the result of such experiment
would be though.

-- 
Felipe Contreras

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

[Felipe Contreras]

David Kastrup wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> > 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.
> 
> Let me spell it out for you.  Michael states "I agree with Junio.  There
> are good technical arguments for and against moving git-remote-hg out of
> contrib."  Since there are arguments for both sides, the decision boils
> down to a judgment call.  Michael states that he condones the choice
> Junio made, based on the reasoning he gave.

Junio didn't give any reasoning, he deferred by saying "that reason some
other guy gave" and he never explained which reason that was.

Which is why I'm pretty sure Michael Haggery does not have actually any
reason.

He even admitted almost as much by saying he doesn't really care much
about these "small technical issues", which are not important to him.

So until Michael explains his reasons, I'll assume he has none. And so
should any rational person.

-- 
Felipe Contreras

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

[Felipe Contreras]

Michael Haggerty wrote:
> On 05/12/2014 02:29 PM, Felipe Contreras wrote:
> > Michael Haggerty wrote:
> > [...]
> >> 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