From: Junio C Hamano <hidden> Date: 2016-06-15 23:01:08
Felipe Contreras [off-list ref] writes:
Philippe Vaucher wrote:
quoted
quoted
quoted
I have had patches and contributions rejected in the past, sometimes
rudely. Same has happened to many others, if you contribute long
enough, it is pretty much guaranteed that it will happen to you.
Maintainer is wrong, or you are wrong, or someone is just having a bad
day.
This is not about a couple of patches I worked in a weekend being
rejected. This is about the work I've been doing since the past two
years almost like a full-time job dropped to the floor with no
explanation at all. I started with the expectation that they were going
to move to the core, because Junio said so, then he changed his mind and
didn't want to explain his reasoning.
It's not just a bad day.
You are not paying attention at all.
Junio did *not* use my social manners as a reason to block the
graduation, nor the quality of the code, he used a *TECHNICAL* reason.
Prior to his decision there were no complaints about my "manners" since
I returned. It was his *TECHNICAL* decision that triggered this.
Junio never explained his *TECHNICAL* reason, and Michael Haggerty
simply said "there are good technical arguments for and against
moving git-remote-hg out of contrib", that was all his explanation for
the *TECHNICAL* reason.
You, and other people, are using the behavior I displayed *AFTER* Junio
made his *TECHNICAL* decision as the cause for his decision not to
graduate. That's a wrong direction fallacy.
I am not interested in distinction between technical and social that
much. The points that were raised in the thread started by John
Keeping, and some of the points that came to my mind while on that
thread, even though I may not have mentioned in *that* thread, that
affected the way *I* thought about the issue are these (not
exhaustive):
- We may be painted in a hard place if remote-hg or remote-bzr take
us to a position where the Git as a whole is blocked while it is
incompatible with the other side.
Maintaining it as an independent project (aka Unbundling) would
eliminate that risk, instead of having to handwave and say "that
risk does not exist".
- A remote-helper has to depend on both sides. Keeping it in
either contrib/ or in core, as opposed to unbundling, may make
things easier for the remote-helper maintainer, because at least
it would allow the helper to advance with Git in lock-step (but I
never heard that you do not prefer unbundling for this reason).
- In a longer term, a properly maintained remote-helpers should
work with wide varieties of Git and the remote system versions
anyway, so unbundling would be logically the more "correct" thing
to do.
- Unbundling would make it less easier to use the remote-helpers
for people who are used to keep up with my tree and pick them up
from contrib/, but that is a tiny minority these days. Most
people use what distros package, and the distros that already
package contrib/ remote-helpers will switch their upstream to
unbundled repositories in order not to regress their packages for
their users.
- On the other hand, unbundling will make it easier for the the
end-users (both the ones who are fed distro packaged versions and
the ones who build from the source _and_ who overcome the "less
easier because now they have to pull from not just me but from
the unbundled places" inconvenience) to keep up with the
leading/bleeding edge, because the remote-helpers do not have to
freeze at the same time other parts of Git are frozen before the
release, and users and distros can pick improved remote-helpers
up and even "mix and match", when they have some other reason
that prevents them from updating Git itself.
- Unbundling would also involve the risk of making them obscure,
and the original reason why we added contrib/ area to host
"having something is often better than having nothing" tools,
even if some of them were of lessor quality, was exactly that.
While building the momentum and the Git community, it was
necessary to have a nursery. That reasoning no longer applies
these days, and we have seen examples of third-party independent
products that can improve the users' Git life flourishing.
"We have less need for a nursery" is not a reason to kick bundled
things out that want to be bundled, but it tells us that we no
longer have to be afraid of unbundled things dying in obscurity,
if there are other reasons that tell us unbundling is better.
I may be missing some others, and I would be lying if I did not at
all think of the "net liability" issue Michael brought up, but the
above that does not include anything you labelled as "social
manners" was more or less enough to convince me to say
... and I am inclined to be persuaded that the users of
remote-hg/bzr may better off if they are unbundled from my tree.
in
http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248242
That is not to say that I disagree with Michael and social issues do
not matter.
From: Felipe Contreras <hidden> Date: 2016-06-15 23:01:09
Junio C Hamano wrote:
Felipe Contreras [off-list ref] writes:
quoted
Junio never explained his *TECHNICAL* reason, and Michael Haggerty
simply said "there are good technical arguments for and against
moving git-remote-hg out of contrib", that was all his explanation for
the *TECHNICAL* reason.
I am not interested in distinction between technical and social that
much. The points that were raised in the thread started by John
Keeping, and some of the points that came to my mind while on that
thread, even though I may not have mentioned in *that* thread, that
affected the way *I* thought about the issue are these (not
exhaustive):
Let's be clear; the discussion in that thread was contrib vs. core. Most
of the points you mention below are not related to that.
== contrib vs. core ==
This is the only point relevant to contrib vs. core:
- We may be painted in a hard place if remote-hg or remote-bzr take
us to a position where the Git as a whole is blocked while it is
incompatible with the other side.
It will never happen. I already argued against it[1], multiple times.
Essentially making the tests optional removes any possibility of
blockage (pluse many more arguments).
This is the crux of the problem, because as far as I know, it's the only
suppsed argument against contrib vs. core. An argument very weak and
already refuted.
I repeatedly asked Junio to clarify his reasoning, because it can't
possibly be that this is the only reason, and that's the full rationale.
If this is it. Then it's very clear: core wins.
== bundle vs. unbundle ==
The rest of the arguments are *not* related to contrib vs. core. They
are a red herring, but I'll answer anyway.
- A remote-helper has to depend on both sides. Keeping it in
either contrib/ or in core, as opposed to unbundling, may make
things easier for the remote-helper maintainer, because at least
it would allow the helper to advance with Git in lock-step (but I
never heard that you do not prefer unbundling for this reason).
I am the maintainer I told you that wasn't the way to go and I'm telling
you again.
- In a longer term, a properly maintained remote-helpers should
work with wide varieties of Git and the remote system versions
anyway, so unbundling would be logically the more "correct" thing
to do.
I already argued against this (and so did you[2]); the same argument
applies to git-p4, git-cvs, git-svn, git-archimport, etc.
We are not seeing efforts to unbundle those. Why? Because it would be
detrimental to our users, for many reasons, starting by the fact that
there's no good visibility of out-of-tree tools.
- Unbundling would make it less easier to use the remote-helpers
for people who are used to keep up with my tree and pick them up
from contrib/, but that is a tiny minority these days. Most
people use what distros package, and the distros that already
package contrib/ remote-helpers will switch their upstream to
unbundled repositories in order not to regress their packages for
their users.
That is not true. Distributions mostly put everything in contrib/ into
/usr/share/git without much care about what does what. If something is
missing the users might notice, but the packages wouldn't. It would
require different packagers that care to create the new packages, if it
happens at all. The new packages might be created in a ppa, or some
other third-party place not very visible.
If proper packages manage to end up in the main distribution
repositories, it will take a long time, and in the meantime users will
be left with a bad taste in their mouth.
It will take even more time if these tools remain in contrib/ because
nobody will notice anything, until bugs start to pile up.
- On the other hand, unbundling will make it easier for the the
end-users (both the ones who are fed distro packaged versions and
the ones who build from the source _and_ who overcome the "less
easier because now they have to pull from not just me but from
the unbundled places" inconvenience) to keep up with the
leading/bleeding edge, because the remote-helpers do not have to
freeze at the same time other parts of Git are frozen before the
release, and users and distros can pick improved remote-helpers
up and even "mix and match", when they have some other reason
that prevents them from updating Git itself.
Users don't care much about being on the bleeding edge. They care that
their tools keep working and in the same way. For that it's more
important that the maintainers have as many eyes as possible no the
patches. And sending the patches on git@vger.kernel.org has certain
helped in that regard. You want to take that away from them.
Additionally, they care that the tools are easy to set up. Being able to
clone Mercurial repositories from an out-of-the-box version of Git is
much more important to them than being "on the bleeding edge".
Plus this also applies got git-p4, git-cvs, git-svn, etc. It's not a
good argument for them, and it's not a good argument for
git-remote-hg/bzr either.
- Unbundling would also involve the risk of making them obscure,
and the original reason why we added contrib/ area to host
"having something is often better than having nothing" tools,
even if some of them were of lessor quality, was exactly that.
While building the momentum and the Git community, it was
necessary to have a nursery. That reasoning no longer applies
these days, and we have seen examples of third-party independent
products that can improve the users' Git life flourishing.
This is not true. The reasoning behind the contrib/ nursery was
*entirely* so that they could move into the core, just like you said
they would since day one [3]. If they are not going to be part of the
core, all the time in contrib was wasted.
If they had been an out-of-tree project, interest would slowly build up
to the point where separate packages get created and slowly build
popularity.
Instead what we would have is a big breakage in user expectations,
followed by uncertain period of time where the tools are not packaged.
And git-remote-hg/bzr would have to compete with other tools who have
had longer time in the free-market, and thus have more publicity in the
form of blog posts, etc. There's already multiple git-remote-hg and
git-remote-bzr, and it would be hard to explain which is which and why
you would want to use these particular ones. The only salient point
would be that they were once part of the git.git repository, but that
begs the question; why did they got dropped. And the fact that you
haven't been able to provide a good explanation doesn't help.
If on the other hand they become part of the core as was the intention
since day one, none of this would happen, and *everybody* would be happy.
"We have less need for a nursery" is not a reason to kick bundled
things out that want to be bundled, but it tells us that we no
longer have to be afraid of unbundled things dying in obscurity,
if there are other reasons that tell us unbundling is better.
Do we no longer have to be afraid of that? WHY? All the responses from
the contrib cleanup patches seem to suggest that pretty much *everyone*
is afraid the contrib tools would die in obscurity if unbundled.
I may be missing some others, and I would be lying if I did not at
all think of the "net liability" issue Michael brought up, but the
above that does not include anything you labelled as "social
manners" was more or less enough to convince me to say
... and I am inclined to be persuaded that the users of
remote-hg/bzr may better off if they are unbundled from my tree.
in
http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248242
This is a huge distraction and a red herring. The issue discussed never
was bundle vs. unbundle, it was contrib vs. core. After answering the
original issue we could discuss contrib vs. unbundle, or core vs.
unbundle. But you tainted the discussion by deciding on the case bundle
vs. unbundle before it was even discussed, and with no explanation.
The jury is still out in the case core vs. unbundle, and if the best
arguments in favor of unbundle are the ones you just brought up, then
the case is pretty one-sided.
Either way the case is closed, because the judge already passed
veredict, even before there was a chance to bring any arguments.
== Conclusion ==
Do not be fooled. There was only one argument that blocked the
graduation to the core, it was a bad one, and it was refuted pretty
decisevely; remote-hg/bzr should move to the core.
If and when foreign scm tools such as git-p4, git-cvs, git-svn and
git-remote-hg/bzr should move out of the core and be unbundled is a
separate matter that hasn't been discussed yet. When such discussion
happens it should take more than the weak arguments Junio has put forth
in order to determine their faith. And when doing so there should be
measures in place to make sure the transition is as smooth as possible,
like a page that lists these tools, and documentation about the best
practices that these out-of-tree tools should follow (I already argued
for that).
The facts remain clear: Junio made a hasty decision with regards to
git-remote-hg/bzr, which he would *never* do with other tools in exactly
the same position: git-p4, git-svn, etc.
[1] http://article.gmane.org/gmane.comp.version-control.git/248685
[2] http://article.gmane.org/gmane.comp.version-control.git/248156
[3] http://article.gmane.org/gmane.comp.version-control.git/220277
--
Felipe Contreras
From: Martin Langhoff <hidden> Date: 2016-06-15 23:01:09
On Wed, May 14, 2014 at 7:28 PM, Felipe Contreras
[off-list ref] wrote:
Do we no longer have to be afraid of that? WHY? All the responses from
the contrib cleanup patches seem to suggest that pretty much *everyone*
The responses also been clear in that you are toxic. You've hijacked
this mailing list on a personal crusade over a particular point over
which Junio has discretion.
We get it. You disagree with the maintainer. It is clear now. Learn to
live with it; or at least let everyone else be.
Can we call Hitler on this one and close these threads now?
You sent a nice email saying bridges are burned. We get the point.
It's over. Bridges burned. NO CARRIER.
Bye now.
m
--
martin.langhoff@gmail.com
- ask interesting questions
- don't get distracted with shiny stuff - working code first
~ http://docs.moodle.org/en/User:Martin_Langhoff
From: Felipe Contreras <hidden> Date: 2016-06-15 23:01:09
Martin Langhoff wrote:
On Wed, May 14, 2014 at 7:28 PM, Felipe Contreras
[off-list ref] wrote:
quoted
Do we no longer have to be afraid of that? WHY? All the responses from
the contrib cleanup patches seem to suggest that pretty much *everyone*
The responses also been clear in that you are toxic.
You are replying to a mail about a *TECHNICAL* reason. Junio made a good
job of concentrating on the technical side.
If you are not willing or unable to concentrate on the technical side,
reply to something else, you are just tainting the discussion.
If you are willing to concede that Junio made a wrong technical
decision, I'd be willing to discuss about the social issues that
happened *after* that with you. But I doubt you are interested in doing
either one of those, so I don't don't see what's the point of you even
replying.
--
Felipe Contreras
From: Junio C Hamano <hidden> Date: 2016-06-15 23:01:11
Felipe Contreras [off-list ref] writes:
Junio C Hamano wrote:
quoted
Felipe Contreras [off-list ref] writes:
quoted
Junio never explained his *TECHNICAL* reason, and Michael Haggerty
simply said "there are good technical arguments for and against
moving git-remote-hg out of contrib", that was all his explanation for
the *TECHNICAL* reason.
quoted
I am not interested in distinction between technical and social that
much. The points that were raised in the thread started by John
Keeping, and some of the points that came to my mind while on that
thread, even though I may not have mentioned in *that* thread, that
affected the way *I* thought about the issue are these (not
exhaustive):
Let's be clear; the discussion in that thread was contrib vs. core. Most
of the points you mention below are not related to that.
== contrib vs. core ==
This is the only point relevant to contrib vs. core:
quoted
- We may be painted in a hard place if remote-hg or remote-bzr take
us to a position where the Git as a whole is blocked while it is
incompatible with the other side.
It will never happen. I already argued against it[1], multiple times.
Essentially making the tests optional removes any possibility of
blockage (pluse many more arguments).
I already said that your "It will never happen" is a handwaving, and
I already saw you "argued against it". There is no point repeating
that exchange. We both know, and bystanders with popcorns in their
hands also know, that we have different opinions.
You may have been interested in contrib/core in the thread, but that
does not prevent others from considering other aspects of the issue
and different and possibly better solutions, which was to unbundle.
I was very confident back in that thread that the remote Hg bridge
would not merely survive but would serve its users well as a
standalone project, and the level of confidence was actually a lot
higher than for a hypothetical case where other "already in-core"
bridges like git-svn/p4 are somehow forced to become standalone,
simply because of the difference in the depths of involvement of
respective area maintainers. Without meaning any disrespect to Eric
or Pete, I think my prodding them (by forwarding issues and proposed
patches by others to them when I see them on the list) has been
helping the area maintainers who have other time and attention
obligations to help us, by drawing their attention and making their
workload smaller (they can only Ack and have me apply, instead of
maintaining a separate tree). There is a greater risk for these
bridges to become unmaintained if we do not have them in my tree,
and that would only hurt our users. In the ideal world, it may be
better if it weren't that way, but at the same time, new issues that
changing time brings to them seem to be handled more or less OK, so
we have to be content with the status quo.
But I did not see that particular risk at all for the remote Hg
bridge. You have been very interested in maintaining it, and I
don't think I ever had to prod you to respond to an issue raised on
the list. It is an apples-and-oranges comparison to bring up
git-svn/p4.
Besides, I want to see the "git-core has the best thing among
competing implementations for a specific niche subtask" perception
changed in the longer term so that it becomes natural for users to
say something like "For this particular task, there is no support in
what comes with core (or there is a tool that comes with core to
address similar issues but in a way different from what you want),
and the go-to tool these days for that kind of task is to use this
third-party plugin", because it is simply unrealistic to expect my
tree to forever be the be-all destination for everything.
Things like "git imerge" are helping us to go in that direction. I
was hoping that the remote Hg bridge to be capable of becoming the
first demonstration to graduate out of contrib/ that shows the users
that is the case, not with just talk but with a specific example.
Anyway, the above is only within the discussion theme of John
Keeping's thread [*1*]. You seem to be adamant that you do not
consider other people's opinions that came in later threads you
started [*2*], and I do not think that is a sensible way to discuss
things.
After seeing these discussions, it tells me that the code is not fit
for the core (also [*3*]), and I think there no longer is any reason
for us to still talk only about contrib vs core. As you already
said, you do not want to see them in contrib/, and as you already
saw, everybody other than you do not want to see them in core and
some of them do not want to even see them in contrib/ for that
matter.
I do not see that there is any direction other than out.
[Reference]
*1* http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248167
*2* http://thread.gmane.org/gmane.comp.version-control.git/248705
*3* http://thread.gmane.org/gmane.comp.version-control.git/248063/focus=248727
From: Felipe Contreras <hidden> Date: 2016-06-15 23:01:12
Junio C Hamano wrote:
Felipe Contreras [off-list ref] writes:
quoted
== contrib vs. core ==
This is the only point relevant to contrib vs. core:
quoted
- We may be painted in a hard place if remote-hg or remote-bzr take
us to a position where the Git as a whole is blocked while it is
incompatible with the other side.
It will never happen. I already argued against it[1], multiple times.
Essentially making the tests optional removes any possibility of
blockage (pluse many more arguments).
I already said that your "It will never happen" is a handwaving, and
I already saw you "argued against it".
This is a red herring. Ignore the fact that it will never happen (which
it won't), the next point remains a FACT, and you conveniently ignore
it.
ANSWER THIS:
quoted
Essentially making the tests optional removes any possibility of
blockage (pluse many more arguments).
If the tests are optional, it doesn't matter if such change you are
worried about happens or not (it won't).
That's all there is to it. You made a wrong call. The tools *can* move
into the core, and you said they couldn't.
You may have been interested in contrib/core in the thread, but that
does not prevent others from considering other aspects of the issue
and different and possibly better solutions, which was to unbundle.
That is IRRELEVANT to the fact that the tools *could* move into the
core. You are using arguments (refuted) to demonstrate that the tools
*might be better served* by being unbundled, in order to explain why
they *could not* move into the core.
That's a red herring.
I was very confident back in that thread that the remote Hg bridge
would not merely survive but would serve its users well as a
standalone project,
And you were wrong.
There is a greater risk for these bridges to become unmaintained if we
do not have them in my tree, and that would only hurt our users.
But I did not see that particular risk at all for the remote Hg
bridge. You have been very interested in maintaining it, and I
don't think I ever had to prod you to respond to an issue raised on
the list. It is an apples-and-oranges comparison to bring up
git-svn/p4.
In other words; if I had done a poorer job of maintaining these tools,
they would have had a higher chance of moving into the core?
If that's the case I would gladly stop any maintenance on them. Just say
the word.
I worked extremely hard so they could become part of the core, if being
part of the core means I have to maintain them less, so be it.
Besides, I want to see the "git-core has the best thing among
competing implementations for a specific niche subtask" perception
changed in the longer term so that it becomes natural for users to
say something like "For this particular task, there is no support in
what comes with core (or there is a tool that comes with core to
address similar issues but in a way different from what you want),
and the go-to tool these days for that kind of task is to use this
third-party plugin",
Where are you saying that? Nowhere, that's where. Therefore every tool
you unbundle, you are throwing to the wolves.
Things like "git imerge" are helping us to go in that direction. I
was hoping that the remote Hg bridge to be capable of becoming the
first demonstration to graduate out of contrib/ that shows the users
that is the case, not with just talk but with a specific example.
You told me you wanted them to move to the core, you even moved them to
the core.
Then after years of work you change your mind, AGAINST my explicit will
and with clear strong arguments AGAINST your apparently newly conceived
idea. And idea you didn't explain clearly, and which you didn't give any
chance of being refuted.
In other words; an idea which very well COULD BE WRONG, and which very
well could impact negatively many Git users.
But you cannot even ponder the notion that you could possibly be wrong.
After seeing these discussions, it tells me that the code is not fit
for the core (also [*3*]), and I think there no longer is any reason
for us to still talk only about contrib vs core. As you already said,
you do not want to see them in contrib/,
No, I want to see them in the core, and you said you did too. More
importantly the vast majority of our users would want to see them in the
core, therefore the discussion of contrib vs. core is pretty much
relevant, but you don't care about them, do you?
As I said, I will complain about this publicly _to our users_, which you
are disregarding completely with this poorly thought decision and the
subsequent ones.
--
Felipe Contreras
From: William Giokas <hidden> Date: 2016-06-15 23:01:12
On Fri, May 16, 2014 at 03:08:51AM -0500, Felipe Contreras wrote:
Junio C Hamano wrote:
quoted
Felipe Contreras [off-list ref] writes:
quoted
quoted
== contrib vs. core ==
This is the only point relevant to contrib vs. core:
quoted
- We may be painted in a hard place if remote-hg or remote-bzr take
us to a position where the Git as a whole is blocked while it is
incompatible with the other side.
It will never happen. I already argued against it[1], multiple times.
Essentially making the tests optional removes any possibility of
blockage (pluse many more arguments).
I already said that your "It will never happen" is a handwaving, and
I already saw you "argued against it".
This is a red herring. Ignore the fact that it will never happen (which
it won't), the next point remains a FACT, and you conveniently ignore
it.
It may not block git being released, but as we can see from the recent
patches that were needed to enable hg 3.0 support it can break and would
have to follow *both* mercurial and git upstreams, not just git's. After
thinking about this for a while, I would have to agree with Junio That
it's better if a bridge between to actively developed applications not
be coupled to one.
This does not mean that I think git-remote-hg is not of a quality to be
in the git.git tree, but it is simply a fact of development and
stability. If git's remote-helper stuff changes but mercurial doesn't,
we're fine because, having seen the speed of your fixes, we would have a
fix before the next release without a doubt. However, if mercurial
changes, like it just did, then git itself would need to make a release
to have it actually work with the newest release.
Having the tool out of tree allows the maintainer to fix things on both
ends and release independently so that both situations above can be
solved without any real hassle on git or mercurial's side.
This goes for bzr, too, but it looks to be changing less quickly.
tl;dr: This may not block a release, but it will make releases a lot
more dependent on outside forces.
Thanks,
--
William Giokas | KaiSforza | http://kaictl.net/
GnuPG Key: 0x73CD09CF
Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF
From: Felipe Contreras <hidden> Date: 2016-06-15 23:01:12
William Giokas wrote:
On Fri, May 16, 2014 at 03:08:51AM -0500, Felipe Contreras wrote:
quoted
This is a red herring. Ignore the fact that it will never happen (which
it won't), the next point remains a FACT, and you conveniently ignore
it.
It may not block git being released, but as we can see from the recent
patches that were needed to enable hg 3.0 support it can break and would
have to follow *both* mercurial and git upstreams, not just git's.
Indeed, it *can* happen, nobody has argued otherwise. The thing is how
*likely* is it that it will happen again.
As I said, in my experience developing this there has never been a
single instance where such a change was required for *newer* versions of
Mercurial.
From what I can tell this is an exceptional situation.
And it makes sense that when it happened, it happened exactly in the
part where I wrote custom push() method. Mercurial has unstable API, but
in unstable API's are part that are more stable than others. Generally
the higher level the API is, the more stable it tends to be.
The Linux kernels makes an even weaker promise of API stability than
Mercurial does, but even then, the higher the API you use, the less
likelihood you have of breakage. I've seen this in practice many times.
And it does makes sense that for practical purses Mercurial would try to
avoid changes in the higher level API, which require changes in many
places, and not so much in lower level APIs, which might require a few
changes here and there.
The problem is that in order to replace the higher level API push(), I
had to use the lower level API, and that's where the breakage happened,
it was not unlikely. It is unlikely that another change in this
particular API will happen soon, but not extremely so.
As I already explained, this can be mitigated by contacting the
Mercurial developers and figure out if their high-level API can
accommodate the kind of functionality git-remote-hg needs. Maybe by
adding a new option, or maybe by adding another high-level helper
function.
Either way, I doubt Junio is qualified at all to discern between the
likelihood of future Mercurial API changes that would break
git-remote-hg. He has seen one, and he is wrongly assuming there are
more to come.
After thinking about this for a while, I would have to agree with
Junio That it's better if a bridge between to actively developed
applications not be coupled to one.
How exactly would it be better?
If you concede that the Git release wouldn't be affected, then assuming
a hypothetical future where git-remote-hg is bundled, and we have a
Mercurial API breakage, we would have:
Git < v2.5 fail, Git >= 2.5 get the fix
If we unbundle, we have:
git-remote-hg < v0.5 fail, git-remote-hg >= v0.5 get the fix
What is the big difference?
I presume you would say that git-remote-hg v0.5 could be released
earlier than Git v2.5, so the users would get the fix faster. However,
that is not the case if the breakage is detected *before* the Mercurial
release happened, in which case both Git v2.4 and git-remote-hg v0.4
would already contain the fix, and it doesn't matter much which was
released first.
The problem is that I wasn't doing the continuous integration with the
development version of Mercurial, which I am now, so these kind of
exceptional issues would be detected earlier.
Moreover, it is likely that the distribution package for git-remote-hg
would not be maintained as rigorously as the Git package. It might not
even be part of the official packages (e.g. ppa or AUR). Therefore, even
if the git-remote-hg v0.4 happens earlier, it might reach the users
later.
Furthermore, we are talking about a single script that can be installed
by hand easily. The users can simply override their distribution's
script and install by hand the latest version, as many have been doing
already when they report errors and want the latest fix.
Even more. git-remote-hg will not have maintenance releases, if an
exceptional issue like this happens, it can be back-ported to Git v2.3.x,
Git v2.2.x, and so on.
It seems like a very feeble argument in favor of unbundling *at best*.
This does not mean that I think git-remote-hg is not of a quality to be
in the git.git tree, but it is simply a fact of development and
stability. If git's remote-helper stuff changes but mercurial doesn't,
we're fine because, having seen the speed of your fixes, we would have a
fix before the next release without a doubt. However, if mercurial
changes, like it just did, then git itself would need to make a release
to have it actually work with the newest release.
That is not true. In this particular case, because I didn't build
against the development version of Mercurial, yes, but not for the
future.
If I had the tests I have in place now, we would have detected the
change earlier, and Git v1.9.2 would *already* contain the fix, and when
Mercurial v3.0 got released we wouldn't need to make a Git release in
response (same goes for unbundled git-remote-hg).
Having the tool out of tree allows the maintainer to fix things on both
ends and release independently so that both situations above can be
solved without any real hassle on git or mercurial's side.
As I said; that won't happen. This was an exceptional situation for
different reasons.
If git-remote-hg was unbundled, and the correct tests in place, I would
have v0.2 already with the fix for hg 3.0, and when hg 3.0 got released
I wouldn't be forced to make another v0.2 release. Additionally, I would
not need to make the v0.2 release because of a fix for hg 3.0-dev as
merged.
In other words; the releases wouldn't be as tightly coupled as you make
them seem.
This goes for bzr, too, but it looks to be changing less quickly.
More like not at all.
tl;dr: This may not block a release, but it will make releases a lot
more dependent on outside forces.
tl;dr: That won't happen. Even if it did, it would happen in the
unbundled release a well.
Also note that Junio never brought these points, and they were never
discussed.
I think if I had the tests for the Mercurial development version, the
fix for hg 3.0 would be already released in Git 1.9.2, and I find it
very likely that the graduation to the core would not have been tainted
by this extremely exceptional situation, and the graduation would
continue just fine for Git v2.1.
Sadly we would never know, because people are not good with thought
experiments, and they can't see what such a situation would look like,
and how a similar exceptional situation would look just like that. Not
to mention the fact that suck situation wouldn't happen at all.
Cheers.
--
Felipe Contreras
From: William Giokas <hidden> Date: 2016-06-15 23:01:12
On Fri, May 16, 2014 at 05:21:36AM -0500, Felipe Contreras wrote:
How exactly would it be better?
If you concede that the Git release wouldn't be affected, then assuming
a hypothetical future where git-remote-hg is bundled, and we have a
Mercurial API breakage, we would have:
Git < v2.5 fail, Git >= 2.5 get the fix
If we unbundle, we have:
git-remote-hg < v0.5 fail, git-remote-hg >= v0.5 get the fix
What is the big difference?
It's a matter of scope and where the releases happen, that is all.
Thank you,
--
William Giokas | KaiSforza | http://kaictl.net/
GnuPG Key: 0x73CD09CF
Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF
From: Felipe Contreras <hidden> Date: 2016-06-15 23:01:12
William Giokas wrote:
On Fri, May 16, 2014 at 05:21:36AM -0500, Felipe Contreras wrote:
quoted
How exactly would it be better?
If you concede that the Git release wouldn't be affected, then assuming
a hypothetical future where git-remote-hg is bundled, and we have a
Mercurial API breakage, we would have:
Git < v2.5 fail, Git >= 2.5 get the fix
If we unbundle, we have:
git-remote-hg < v0.5 fail, git-remote-hg >= v0.5 get the fix
What is the big difference?
It's a matter of scope and where the releases happen, that is all.
Of course the core vs. out-of-tree question is a matter of where the
releases happen. The question here was: in which way is out-of-tree a
better place?
If it's a matter of scope, that is; should a foreign vcs interface tool
be bundled in the Git core? Then that question applies not only to
git-remote-hg/bzr, but also git-p4, git-cvs, git-svn, and others.
The answer to the first question seems to be; it's not at all clear (in
fact there doesn't seem to be any valid argument in favour of
out-of-tree). The answer to the second question is; we are not asking
that question right now (for the moment foreign vcs tools should remain
part of the Git core).
I started the graduation series by saying "there doesn't seem to be any
good reason not to", and Junio agreed. Now Junio doesn't agree, but it's
till the case there's no good reason not to.
--
Felipe Contreras