From: Junio C Hamano <hidden> Date: 2016-06-15 23:01:03
Felipe Contreras [off-list ref] writes:
Junio C Hamano wrote:
quoted
Felipe Contreras [off-list ref] writes:
quoted
Here's a bunch of tests more, and a fixes for Mercurial v3.0.
I think the discussion with John Keeping hints that we shouldn't be
rushing fc/remote-helpers-hg-bzr-graduation
Really? Based on what reasoning? I have proven his reasoning to be
basically wrong.
Perhaps s/proven/convinced myself only/; you didn't prove it to me
and I doubt you proved it to John.
quoted
For example, I see
from mercurial import changegroup
if check_version(3, 0):
cg = changegroup.getbundle(...)
else:
cg = repo.getbundle(...)
and offhand it was unclear if the unconditional import was a
mistake.
Of course it wasn't a mistake.
I doubt about the "Of course" part. The first reaction after seeing
that the new "changegroup" is used only inside check_version(3,0)
and nowhere else was to wonder if that import is necessary (or even
safe) for the pre-v3.0 versions.
From: Felipe Contreras <hidden> Date: 2016-06-15 23:01:03
Junio C Hamano wrote:
Felipe Contreras [off-list ref] writes:
quoted
Really? Based on what reasoning? I have proven his reasoning to be
basically wrong.
Perhaps s/proven/convinced myself only/; you didn't prove it to me
and I doubt you proved it to John.
And you are still conveniently avoiding the question:
Based on what reasoning?
quoted
Of course it wasn't a mistake.
I doubt about the "Of course" part. The first reaction after seeing
that the new "changegroup" is used only inside check_version(3,0)
and nowhere else was to wonder if that import is necessary (or even
safe) for the pre-v3.0 versions.
I don't care about your first reaction. If that was only present in
newer versions, how do you think it would pass the testing on older
versions?
https://travis-ci.org/felipec/git
Normally I would explain the details of why this is the case, and send
the crash regresion fix for v2.0 with a clear explanation, but since you
are adamant in threating git-remote-hg/bzr as just another crappy
contrib script that doesn't even have tests like diff-highlight or
hg-to-git. Why would I care?
The fact that I'm the maintainer and I say it'ss good should be good
enough, and if the current version in "master" renders unusable the
existing Mercurial clones, hey, it's only in contrib, right?
--
Felipe Contreras
From: Junio C Hamano <hidden> Date: 2016-06-15 23:01:03
Felipe Contreras [off-list ref] writes:
And you are still conveniently avoiding the question:
Based on what reasoning?
Go re-read what was already said in the thread. I still think
remote-hg and remote-bzr can and will flourish on their own merit,
and unbundling will be better for the end users for the reasons
stated there already.
Having said that, I've been thinking (not because of this thread,
but because I like imerge better and better these days) that there
should be a much better way to have a list of recommended third-party
plug-ins that enrich the Git ecosystem. We have
https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools
(Jakub cc'ed as he often nudges those who announce their tools to
add an entry there) but honestly, git-scm.com is the first site the
end users who do not hack on Git would visit, and we probably should
have a catalog there (Scott and Peff cc'ed for that site). One way
to help it may be to add a Documentation/gitthirdparty-tools.txt in
my tree that would automatically be pulled into git-scm.com site as
a part of the manual. A richer ecosystem with tools outside my tree
would not materialize unless there is such a mechanism to advertise
the existence of them, and having to include a copy of each and
every third-party tools in my tree and keeping them relatively fresh
is not going to scale in the long run (Michael and Matthieu Cc'ed as
I saw exchanges on multimail in a near-by thread).
Such a file would probably cluster "plugins" into different
categories (post-receive hooks, remote-helpers, mergetools, etc.)
and limit the entry descriptions to a single paragraph of several
lines tops, with URL referring to the third-party maintainer's site
(e.g. a repository at GitHub).
quoted
quoted
Of course it wasn't a mistake.
I doubt about the "Of course" part. The first reaction after seeing
that the new "changegroup" is used only inside check_version(3,0)
and nowhere else was to wonder if that import is necessary (or even
safe) for the pre-v3.0 versions.
I don't care about your first reaction. If that was only present in
newer versions, how do you think it would pass the testing on older
versions?
https://travis-ci.org/felipec/git
Normally I would explain the details of why this is the case, and send
the crash regresion fix for v2.0 with a clear explanation,...
Without such an explanation in the log message, how would you expect
anybody to guess correctly?
Seriously, if you do not care about my first reaction, why do you
even want to live in my tree?
The fact that I'm the maintainer and I say it'ss good should be good
enough, and if the current version in "master" renders unusable the
existing Mercurial clones, hey, it's only in contrib, right?
One potential merit I would see for keeping them in my tree is that
your change will see second opinions from others involved in the
project (including me), without giving a total rein based on the
sub-maintainership alone. All the changes from sub-area maintainers
are vetted by at least two sets of eyeballs that way.
But after having to deal with you and seeing that you do not take
constructive criticism well, I doubt such a possibile merit will
ever materialize in the area where you alone work on. Letting you
do whatever you want in your own tree may benefit the users of
remote-hg/remote-bzr better as the (bitter) second best option.
From: Felipe Contreras <hidden> Date: 2016-06-15 23:01:03
Junio C Hamano wrote:
Felipe Contreras [off-list ref] writes:
quoted
And you are still conveniently avoiding the question:
Based on what reasoning?
Go re-read what was already said in the thread.
I already read it, and I already responded.
I still think remote-hg and remote-bzr can and will flourish on their
own merit,
Oh, you *think*. Well, what if you are wrong?
Or is that never a possibility? You are always right. Right?
Having said that, I've been thinking (not because of this thread,
but because I like imerge better and better these days) that there
should be a much better way to have a list of recommended third-party
plug-ins that enrich the Git ecosystem.
If and when such a mechanism exists, sure, it makes sense to move
functionality like git-p4 and git-remote-hg out of the core and contrib
areas.
But in the meantime what is ready for the core should be in the core.
quoted
Normally I would explain the details of why this is the case, and send
the crash regresion fix for v2.0 with a clear explanation,...
Without such an explanation in the log message, how would you expect
anybody to guess correctly?
I don't. I told you it wasn't a mistake. If that's not enough for you,
that's *your* problem.
*If* git-remote-hg was to be part of the core, then sure, I would care
that you didn't understand why the patch is correct, and I would resend
immediately what a clear explanation.
But since it's only part of the contrib area which has such abundant
crap without documentation or tests. I do not care.
Seriously, if you do not care about my first reaction, why do you
even want to live in my tree?
As I already explained; I don't care about your reaction *because* you
don't want these tools to live in your tree.
quoted
The fact that I'm the maintainer and I say it'ss good should be good
enough, and if the current version in "master" renders unusable the
existing Mercurial clones, hey, it's only in contrib, right?
One potential merit I would see for keeping them in my tree is that
your change will see second opinions from others involved in the
project (including me), without giving a total rein based on the
sub-maintainership alone. All the changes from sub-area maintainers
are vetted by at least two sets of eyeballs that way.
But after having to deal with you and seeing that you do not take
constructive criticism well,
Oh, please. Up to the point where you decided unilaterally to move them
out of the core (they are alread in), all the constructive criticism to
git-remote-hg has been addressed properly.
I have spent an absurdely large amount of time working on git-remote-hg,
and the transport-helper to make sure everything works right. I even started
git-remote-bzr just to prove that the Python git_remote_helpers
framework was not needed, and eventually I made it work better than any
of the alternatives. I had to fight tooth-and-nail to prove that the
msysgit guys were wrong and my patch to handle UNINTERESTING refs
properly was right. Not to mention all the tests, the compatibility with
hg-git, and with gittifyhg, just to prove that my approach was superior
than the alternatives.
I addressed every issue reported constructively, every bug report was
fixed, every patch reviewed and usually improved by me. I made sure
users of older versions wouldn't be affected negatively when the marks
file was upgraded, and I even setup automatic tests for different
versions Bazaar and Mercurial that run every time I push to my
repository.
It is *way* beyond the quality of any other tool in 'contrib/' and even
some tools in the core, like 'git-request-pull' (which has known bugs),
and probably even 'git-pt'.
Even you agreed it would be beneficial to move them out of contrib; it
would benefit *everyone*. And there was no reason not to.
And then some random guy comes with a few bad arguments, and you change
your mind.
That's f*cking double standards. Pure and simple.
If git-remote-hg belongs out-of-tree, so does git-svn and git-p4. If
git-remote-hg belongs in the contrib area, so does git-svn, and git-p4.
After all this insane amout of work you are acting as if git-remote-hg
wasn't ready to move to the core, because I didn't explain *one* commit
properly to you (which happened after this bullshit).
If these helpers are not going to move forward why would I care? Give me
why one good reason why I should give a flying f*ck about the state of
remote-helpers in *your* tree after this (and BTW as things stand now,
it's not good).
It was *your* users who urged me to send my patches upstream.
I doubt such a possibile merit will ever materialize in the area where
you alone work on.
And there it is. Ad hominem rationale.
Letting you do whatever you want in your own tree may benefit the
users of remote-hg/remote-bzr better as the (bitter) second best
option.
If and when there is a mechanism promoting out-of-tree tools, that
might be the case.
In the meantime virtually every tool that is worth using lives in
git.git and is distributed by default. Everything else is sub-par in the
minds of Git users.
One tool being dropped from the tree while other tools remain there is
not going to send a positive message to its users.
If you are so confident git-remote-hg would "flourish" out-of-tree, drop
git-p4 and git-svn, see what is the reaction.
--
Felipe Contreras
From: James Denholm <hidden> Date: 2016-06-15 23:01:03
Felipe, I would ask, suggest, beg, implore you to calm down. It's
generally not a good plan to alienate the maintainer of a project,
regardless of the correctness or incorrectness of one's arguments, but I
fear that's only what you will achieve at the moment.
--
Regards,
James Denholm.
From: Felipe Contreras <hidden> Date: 2016-06-15 23:01:03
James Denholm wrote:
Felipe, I would ask, suggest, beg, implore you to calm down.
I am calmed down. I waited a day before replying to make sure of that.
It's generally not a good plan to alienate the maintainer of a
project, regardless of the correctness or incorrectness of one's
arguments, but I fear that's only what you will achieve at the moment.
He has already alienated me. In fact he asked me before to leave the
mailing list. And I did for a while.
However, at some level he knows my patches are beneficial to the
project, so he is applying them again.
Either way it doesn't matter if I'm calmed down or not, abrassive or
civil, this ad hominmen double standards bullshit is going to continue.
See what was his reply to my mail? *Nothing*.
What was his reply when I argued if he even admitted he could
potentially be wrong, and if so would essentially trash a project I've
worked very hard for? *Nothing*.
What was his reply when I argued that git-remote-hg has more quality
than all the tools in contrib, even some in the core and therefore
doesn't belong there? *Nothing*.
What was his reply when I said double standards were applied for
git-remote-hg. *Nothing*.
How about when I argued there was no mechanism for out-of-tree tools to
be properly maintained and promoted, and moving tools outside of the
tree shouldn't be done before that happens? *Nothing*.
What did he say when I suggested to move out git-p4 and git-svn, if he
is so sure important tools can "flourish" out-of-tree? *Nothing*.
The truth is that it doesn't matter how I present my arguments, calmly
or otherwise. He is *never* going to accept he was wrong, especially not
when that would mean I was right.
Don't expect any more git-remote-hg patches from me. If Junio thinks
it's just another crappy contrib tool, then I'll threat it as one.
And unfortunately Junio would rather let an important part of Git die a
slow death rather than admit he was wrong. Just watch him ignore the
problem.
--
Felipe Contreras
From: Philippe Vaucher <hidden> Date: 2016-06-15 23:01:06
I addressed every issue reported constructively, every bug report was
fixed, every patch reviewed and usually improved by me. I made sure
users of older versions wouldn't be affected negatively when the marks
file was upgraded, and I even setup automatic tests for different
versions Bazaar and Mercurial that run every time I push to my
repository.
It is *way* beyond the quality of any other tool in 'contrib/' and even
some tools in the core, like 'git-request-pull' (which has known bugs),
and probably even 'git-pt'.
Junio, can you comment on this? I understand this probably doesn't
really affect the issue at hand, but it'd help clarify if it's ever
possible to move out of contrib/ nowadays.
If git-remote-hg belongs out-of-tree, so does git-svn and git-p4. If
git-remote-hg belongs in the contrib area, so does git-svn, and git-p4.
Here too, can you clarify a bit about what should be out of tree and
what should be in contrib? I understand that not all rules are set in
stone and that there is an historical baggage for which applying all
rules is probably more trouble than it's worth, but again it's nice to
clarify for future users. Also it'd probably be worth commenting on
unwritten rules about human factors (easyness of communication,
response to criticisim, ability to make concessions, etc).
Philippe
From: Philippe Vaucher <hidden> Date: 2016-06-15 23:01:06
Nevermind, it'd be more efficient to cover this in the other main
thread started by Felipe. You can answer my questions there instead as
it'll likely benefit a wider audience.
Philippe
From: Junio C Hamano <hidden> Date: 2016-06-15 23:01:06
Philippe Vaucher [off-list ref] writes:
quoted
It is *way* beyond the quality of any other tool in 'contrib/' and even
some tools in the core, like 'git-request-pull' (which has known bugs),
and probably even 'git-pt'.
Junio, can you comment on this? I understand this probably doesn't
really affect the issue at hand, but it'd help clarify if it's ever
possible to move out of contrib/ nowadays.
I was originally led to believe that its code quality was good
enough, and that was why I merged the bottom three patches of the
series even down to 'next' in the first place. But after seeing the
"Of course" response that led to [*1*], which made me recall many
patch-review interactions with him, I have started to have doubts.
The code quality of Git that many projects have come to trust their
code with is much more than just "the code at each moment keeps
working for the users as long as the original author is around".
The maintainer of a port to the platform X may lose access to the
platform after switching jobs, the maintainer of a bridge to the
foreign system Y may stop needing to talk to the foreign system
after completing the switch to Git. Anybody can be hit by a bus,
get sick, or simply lose interest in his past creations.
By reading "git log contrib/remote-helpers" and comparing it with
the logs for the rest of the system, you would realize that the
former would not lead to a quality discussion similar to the one
that led to [*2*], which was only possible because the change was
adequately described to allow anybody to understand the original
issue the change was meant to solve. The commit that made the
original change made it easy to ask a critical question: "You are
improving B but at the same time breaking A. Can we do better to
help both A and B?" And it allowed us to move forward without
having to rob Peter to pay Paul.
Granted, these contrib/ patches were applied with the understanding
that contrib/ stuff can be substandard, because having anything is
often better than having nothing, and you cannot go back in time to
update the history to make these commits more useful to others who
will come later. But I would be lying if I said that I would expect
that things will suddenly improve and that the codebase will be
maintained for the long haul in a healthy way the minute we move it
out of contrib/ to the core. Especially after seeing [*1*], which
is just one of the examples that illustrate that there clearly is no
will to explain the changes to help others who come later to help
maintaining the code. "I'll take good care of the codebase", "I've
spend the time to make it better", "Me, me, me", is not what the
open source process is about.
[References]
*1* http://thread.gmane.org/gmane.comp.version-control.git/248063/focus=248341
*2* http://thread.gmane.org/gmane.comp.version-control.git/248075/focus=248204
From: Felipe Contreras <hidden> Date: 2016-06-15 23:01:06
Junio C Hamano wrote:
Philippe Vaucher [off-list ref] writes:
quoted
quoted
It is *way* beyond the quality of any other tool in 'contrib/' and even
some tools in the core, like 'git-request-pull' (which has known bugs),
and probably even 'git-pt'.
Junio, can you comment on this? I understand this probably doesn't
really affect the issue at hand, but it'd help clarify if it's ever
possible to move out of contrib/ nowadays.
I was originally led to believe that its code quality was good
enough, and that was why I merged the bottom three patches of the
series even down to 'next' in the first place. But after seeing the
"Of course" response that led to [*1*], which made me recall many
patch-review interactions with him, I have started to have doubts.
But I would be lying if I said that I would expect
that things will suddenly improve and that the codebase will be
maintained for the long haul in a healthy way the minute we move it
out of contrib/ to the core. Especially after seeing [*1*]
[1] happened *AFTER* you made that stupid decision.
Don't make it look as if your decision was caused by [1], *YOU* caused
[1].
If you want to show that the quality of the commit messages or the code
caused that decision, show an issue in that respect that happened
*BEFORE* your decision.
It is very clear what is happening. Junio made a wrong decision based a
non-issue, then it became abudantly clear that there was no basis for
such decision, this why he never clarified the reasoning behind. Then,
*AFTER* I reacted to his decision he grabbed that opportunity to say
"no, look, this _new_ thing Felipe is doing is the reason". Nice try.
If the behavior in [1] is the reason, the solution is easy; I'll revert
back to my old behavior where I explained everything in detail, and
updated the commit messages if something wasn't clear.
I would:
1. Make sure the regression is fixed Git v2.0
2. Send a clarified patch for the hg 3.0 compatibility
3. Look for other important patches that might be missing and provide
all the details why they are important
4. Rebase and clean the rest of the patches to make sure nothing is
missing
This is what I was going to do anyway *BEFORE* you made that decision.
And this commitment to quality is what I've been doing since day one.
*YOU* changed that by throwing away all my hard work.
If the issue was truly the behavior in [1], the outline above should get
rid of the (fake) problem you mention.
We make a compromise, you ignore this temporary bump (that *you*
caused), and I go "back" to high quality standards (which I was already
doing anyway before). The graduation process continues, and *IF* another
instance like [1] comes (it won't), then the graduation process is
canceled.
Ignoring temporary set-backs, finding common ground, and making an
agreement on future behavior is in the best interest of our users. Will
you do it?
From: Philippe Vaucher <hidden> Date: 2016-06-15 23:01:08
quoted
quoted
It is *way* beyond the quality of any other tool in 'contrib/' and even
some tools in the core, like 'git-request-pull' (which has known bugs),
and probably even 'git-pt'.
Junio, can you comment on this? I understand this probably doesn't
really affect the issue at hand, but it'd help clarify if it's ever
possible to move out of contrib/ nowadays.
I was originally led to believe that its code quality was good
enough, and that was why I merged the bottom three patches of the
series even down to 'next' in the first place. But after seeing the
"Of course" response that led to [*1*], which made me recall many
patch-review interactions with him, I have started to have doubts.
The code quality of Git that many projects have come to trust their
code with is much more than just "the code at each moment keeps
working for the users as long as the original author is around".
The maintainer of a port to the platform X may lose access to the
platform after switching jobs, the maintainer of a bridge to the
foreign system Y may stop needing to talk to the foreign system
after completing the switch to Git. Anybody can be hit by a bus,
get sick, or simply lose interest in his past creations.
By reading "git log contrib/remote-helpers" and comparing it with
the logs for the rest of the system, you would realize that the
former would not lead to a quality discussion similar to the one
that led to [*2*], which was only possible because the change was
adequately described to allow anybody to understand the original
issue the change was meant to solve. The commit that made the
original change made it easy to ask a critical question: "You are
improving B but at the same time breaking A. Can we do better to
help both A and B?" And it allowed us to move forward without
having to rob Peter to pay Paul.
Granted, these contrib/ patches were applied with the understanding
that contrib/ stuff can be substandard, because having anything is
often better than having nothing, and you cannot go back in time to
update the history to make these commits more useful to others who
will come later. But I would be lying if I said that I would expect
that things will suddenly improve and that the codebase will be
maintained for the long haul in a healthy way the minute we move it
out of contrib/ to the core. Especially after seeing [*1*], which
is just one of the examples that illustrate that there clearly is no
will to explain the changes to help others who come later to help
maintaining the code. "I'll take good care of the codebase", "I've
spend the time to make it better", "Me, me, me", is not what the
open source process is about.
Thanks for the explanation. I think it underlines well the A)
technical issues (quality commits) and the B) social issues (ability
to communicate in a friendly way & respond constructively), which we
discovered are both *essential* for contributing to git.
Neglate one or the other, and sooner or later people will refuse to
collaborate with you, because it's just too much "work" to deal with
the downsides.
My hope is that for future events of this nature to be detected sooner
and dealt with more rigidly, e.g by making it clear this or that
behavior is not acceptable. I think part of the problem here is that
we let the situation install itself, by accepting B-side issues just
because A-side was ok, hopeful that B-side would solve itself.
Philippe