[PATCH] remote-helpers: point at their upstream repositories

[PATCH] remote-helpers: point at their upstream repositories

[Junio C Hamano]

Two announcements for their version 0.2 on the list archive are not
quite enough to advertise them to their users.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---

 * I am inclined to queue this for 2.0, and we would also need an
   update to the release notes as well.

   I am undecided about the revert I sent earlier in $gmane/248937;
   with or without it, that is just a contrib/ thing that is not
   well maintained inside our tree anyway.

 contrib/remote-helpers/README | 11 +++++++++++
 1 file changed, 11 insertions(+)
 create mode 100644 contrib/remote-helpers/README

diff --git a/contrib/remote-helpers/README b/contrib/remote-helpers/README
new file mode 100644
index 0000000..72a2df4
--- /dev/null
+++ b/contrib/remote-helpers/README
@@ -0,0 +1,11 @@
+The remote-helper bridges to access data stored in Hg and bzr will be
+maintained outside the git.git tree in the repositories of its
+primary author at:
+
+    https://github.com/felipec/git-remote-hg
+    https://github.com/felipec/git-remote-bzr
+
+As a convenience, copies of the last-bundled version of these two
+remote-helper bridges are kept here, but they may left stale.  Users
+are encouraged to visit the above authoritative repositories for the
+latest versions to get involved in its further developments.
-- 
2.0.0-rc3-431-gba4c34e

RE: [PATCH] remote-helpers: point at their upstream repositories

[Felipe Contreras]

Junio C Hamano wrote:
> Two announcements for their version 0.2 on the list archive are not
> quite enough to advertise them to their users.
> 
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> 
>  * I am inclined to queue this for 2.0, and we would also need an
>    update to the release notes as well.
> 
>    I am undecided about the revert I sent earlier in $gmane/248937;
>    with or without it, that is just a contrib/ thing that is not
>    well maintained inside our tree anyway.
> 
>  contrib/remote-helpers/README | 11 +++++++++++
>  1 file changed, 11 insertions(+)
>  create mode 100644 contrib/remote-helpers/README

NAK.

> diff --git a/contrib/remote-helpers/README b/contrib/remote-helpers/README
> new file mode 100644
> index 0000000..72a2df4
> --- /dev/null
> +++ b/contrib/remote-helpers/README
> @@ -0,0 +1,11 @@
> +The remote-helper bridges to access data stored in Hg and bzr will be

They are called Mercurial and Bazaar.

> +maintained outside the git.git tree in the repositories of its
> +primary author at:
> +
> +    https://github.com/felipec/git-remote-hg
> +    https://github.com/felipec/git-remote-bzr

If this is formatted in asciidoc the links won't appear as links. Do it
as I did:

 * https://github.com/felipec/git-remote-hg
 * https://github.com/felipec/git-remote-bzr

> +As a convenience, copies of the last-bundled version of these two
> +remote-helper bridges are kept here, but they may left stale.  Users
> +are encouraged to visit the above authoritative repositories for the
> +latest versions to get involved in its further developments.

 1) Most users will *never* see this README
 2) Most packagers will never see this README
 3) The people that do read this README will wonder *why* they are now
    maintained separately.

Thanks for wasting all my hard work and sabotaging these projects.

Just as a heads-up. I *will* complain about this publicly and my blog is
visited by thousands of people.

I am requesting one last time:

 1) Add warnings *directly* into the tools themselves ASAP
 
    You didn't have any problems adding warnings for pre-v2.0 behavior
    that changed, nor did you have a problem adding the warning about
    the new zsh completion that moved out of the bash one. Why would you
    have a problem with this one?

 2) Replace the tools with stubs that point to the right locations at
    the earliest convenience

I already sent patches for both, and they were ignored.

A failure to do both will result in a lack of visibility of the new
projects, and a decrease in the quality the users of git.git contrib
area's remote-helpers receive. I will consider that a deliberate attempt
to make the new projects experience unnecessary hardship.

-- 
Felipe Contreras

Re: [PATCH] remote-helpers: point at their upstream repositories

[Jeff King]

On Thu, May 15, 2014 at 03:56:29PM -0700, Junio C Hamano wrote:

> Two announcements for their version 0.2 on the list archive are not
> quite enough to advertise them to their users.

I do not think this README nor a mention in the release notes will get
their attention either, and many people (and packagers) will continue to
use the stale versions forever until those versions go away.

I would much rather _replace_ them with a README in the long run, and
people will notice that they are gone, and then use the README to update
their install procedure.

For 2.0, I am hesitant to do that, though I do not have a problem with a
README like this as a heads-up to prepare packagers for the future. I
say hesitant because people may have been test-packaging 2.0.0-rc3 in
preparation for release, and it will be annoying to them to suddenly
switch.

But that being said, this is Felipe's code. While we have a legal right
to distribute it in v2.0, if he would really prefer it out for v2.0, I
would respect that.

I would prefer to instrument the code with warnings, as that is the sort
of thing a packager moving from -rc3 to -final might not notice, and
shipping the warnings to end users who did not package the software in
the first place will not help them. It is the attention of the packagers
(and source-builders) you want to get.

Of course that is all just my two cents, and is mostly predicated on
there _being_ packagers of the contrib/ tools. It looks like there is a
Debian package in RFP status, but I don't know if that is following the
new release closely. And I don't know about other systems.

-Peff

Re: [PATCH] remote-helpers: point at their upstream repositories

[Paolo Ciarrocchi]

On Fri, May 16, 2014 at 10:41 AM, Jeff King <peff@peff.net> wrote:
> But that being said, this is Felipe's code. While we have a legal right
> to distribute it in v2.0, if he would really prefer it out for v2.0, I
> would respect that.

My understanding is that Felipe would prefer to keep it _in_ the git.git
repository and eventually get it included in the core.

Regards,
-- 
Paolo

Re: [PATCH] remote-helpers: point at their upstream repositories

[Jeff King]

On Fri, May 16, 2014 at 10:55:54AM +0200, Paolo Ciarrocchi wrote:

> On Fri, May 16, 2014 at 10:41 AM, Jeff King <peff@peff.net> wrote:
> > But that being said, this is Felipe's code. While we have a legal right
> > to distribute it in v2.0, if he would really prefer it out for v2.0, I
> > would respect that.
> 
> My understanding is that Felipe would prefer to keep it _in_ the git.git
> repository and eventually get it included in the core.

Yes, sorry if I was unclear. I meant "...if we are going to remove it,
and are considering leaving it in v2.0, we should respect his wishes to
remove it earlier if he wants to".

It is not his decision whether it stays in the core at all. That is
Junio's decision.

-Peff

Re: [PATCH] remote-helpers: point at their upstream repositories

[Felipe Contreras]

Paolo Ciarrocchi wrote:
> On Fri, May 16, 2014 at 10:41 AM, Jeff King <peff@peff.net> wrote:
> > But that being said, this is Felipe's code. While we have a legal right
> > to distribute it in v2.0, if he would really prefer it out for v2.0, I
> > would respect that.
> 
> My understanding is that Felipe would prefer to keep it _in_ the git.git
> repository and eventually get it included in the core.

That is correct.

-- 
Felipe Contreras

Re: [PATCH] remote-helpers: point at their upstream repositories

[Felipe Contreras]

Jeff King wrote:
> On Thu, May 15, 2014 at 03:56:29PM -0700, Junio C Hamano wrote:
> 
> > Two announcements for their version 0.2 on the list archive are not
> > quite enough to advertise them to their users.
> 
> I do not think this README nor a mention in the release notes will get
> their attention either, and many people (and packagers) will continue to
> use the stale versions forever until those versions go away.
> 
> I would much rather _replace_ them with a README in the long run, and
> people will notice that they are gone, and then use the README to update
> their install procedure.
> 
> For 2.0, I am hesitant to do that, though I do not have a problem with a
> README like this as a heads-up to prepare packagers for the future. I
> say hesitant because people may have been test-packaging 2.0.0-rc3 in
> preparation for release, and it will be annoying to them to suddenly
> switch.

I agree, that's why I sent patches that:

 1) Add a warning for v2.0 (which already has problems)

    So everything keeps working as well as in the release candidates,
    except a warning is introduced each time they do a fetch, push, or
    clone operation (use the remote-helpers)

 2) Replace the tools with stubs

    So when they try to fetch, push, or clone, they get an error, and
    nothing else happens.

There's an additional README for the people that want to read more, but
if you don't put stubs, users might try to do what worked before:

  % git clone hg::http://selenic.com/repo/hello
  fatal: Unable to find remote helper for 'hg'

It's much better to report:

  git-remote-hg is now maintained independently.
  For more information visit https://github.com/felipec/git-remote-hg

> But that being said, this is Felipe's code. While we have a legal right
> to distribute it in v2.0, if he would really prefer it out for v2.0, I
> would respect that.

That's right, you have the legal right to distributed it.

It is not my wish to disrupt v2.0, so I think adding a warning should be
sufficient.

Eventually I would prefer if they were not distributed, and replaced
with stubs, not just because it would help the out-of-tree projects
gather more visibility, but also because users would be better served by
not having poorly maintained or unsynchronized code. Hopefully for v2.1.

> I would prefer to instrument the code with warnings, as that is the sort
> of thing a packager moving from -rc3 to -final might not notice, and
> shipping the warnings to end users who did not package the software in
> the first place will not help them. It is the attention of the packagers
> (and source-builders) you want to get.
> 
> Of course that is all just my two cents, and is mostly predicated on
> there _being_ packagers of the contrib/ tools. It looks like there is a
> Debian package in RFP status, but I don't know if that is following the
> new release closely. And I don't know about other systems.

As far as I understand most distributions don't do anything special with
contrib, they just put everything under /usr/share.

It is unlikely packagers will notice any change in one of the dozens
tools in contrib, so they'll make no changes to the packages.

So if the user did:

 % ln -s /usr/share/git/remote-helpers/git-remote-hg ~/bin/git-remote-hg

The expectation would be that this keeps working even if the package
doesn't change (it just adds a warning). Eventually it will stop working
with an error, but the package still won't change.

The distributions that do something special about remote-helpers (AFAIK
it's only debian's git-bzr) would need to change, and sooner or later
they will if there's only stubs there.

Cheers.

-- 
Felipe Contreras

Re: [PATCH] remote-helpers: point at their upstream repositories

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Thu, May 15, 2014 at 03:56:29PM -0700, Junio C Hamano wrote:
>
>> Two announcements for their version 0.2 on the list archive are not
>> quite enough to advertise them to their users.
>
> I do not think this README nor a mention in the release notes will get
> their attention either, and many people (and packagers) will continue to
> use the stale versions forever until those versions go away.
>
> I would much rather _replace_ them with a README in the long run, and
> people will notice that they are gone, and then use the README to update
> their install procedure.
>
> For 2.0, I am hesitant to do that, though I do not have a problem with a
> README like this as a heads-up to prepare packagers for the future. I
> say hesitant because people may have been test-packaging 2.0.0-rc3 in
> preparation for release, and it will be annoying to them to suddenly
> switch.

I share the latter two of the above three.  I was giving distro
packagers a bit more credit for their diligence in knowing what they
are packaging than you seem to be in your first point, but I admit
that it is a blind faith.

> But that being said, this is Felipe's code. While we have a legal right
> to distribute it in v2.0, if he would really prefer it out for v2.0, I
> would respect that.

I am fine with that.

> I would prefer to instrument the code with warnings, as that is the sort
> of thing a packager moving from -rc3 to -final might not notice, and
> shipping the warnings to end users who did not package the software in
> the first place will not help them. It is the attention of the packagers
> (and source-builders) you want to get.

I do agree that a new warning every time it is run will be a more
likely to grab users' attention.  The conclusion I draw from that
shared observation is that the user will be annoyed all the time,
without having a power to do anything about the annoyance, until the
report s/he (or other users) Throw at the packager, even when the
version that was packaged hasn't diverged that much yet, which does
not help end users.

I guess the ideal we want is to make sure their build break.  What
if we do the README in addition to rename contrib/remote-helpers to
contrib/obsolete-remote-helpers (or s/obsolete/graduated/)?  It will
give the packagers three choices and I think it hurts people much
less.

 * The packagers that dump the entirety of contrib/ to somewhere
   without doing anything to expose the scripts to user's PATH do
   not have to do anything.  The users who chose to pick them up
   from there notice the missing contrib/remote-helpers, notice
   "obsolete" (or "graduated"), and read README.

 * The packagers that pick up from contrib/remote-helpers and
   arrange the scripts to be on user's PATH will find their build
   broken, because they are no longer where they expect them to be.
   They will notice "obsolete"(or "graduated"), and read README.

   - They can choose to pick them up from "obsolete", perhaps for
     expediency, perhaps for their change aversion, but that will
     not last once we grabbed their attention, and they will switch
     their upstream in some later release once such a choice makes
     them feel dirty enough.

   - They can choose to switch their upstream right now in response
     to the breakage.

I would say that the options I see are these three, and I would rank
the "warn every time" as less helpful to end-users:

 - rename contrib/remote-helpers to contrib/obsolete-remote-helpers
   and add README to point at the upstream.

 - remove contrib/remote-helpers scripts and add README.

 - warn every time the user runs the scripts.

Or am I reacting to a typo and you meant to say "I would prefer not
to instrument"?  Your "shipping the warnings to end users who did
not package the software will not help" was unclear if you meant the
README that has warning or warning message they have to see every
time from the instrumented code.

Re: [PATCH] remote-helpers: point at their upstream repositories

[Junio C Hamano]

(Sorry if you receive a dup; pobox.com seems to be constipated right now).

Jeff King <peff@peff.net> writes:

> On Thu, May 15, 2014 at 03:56:29PM -0700, Junio C Hamano wrote:
>
>> Two announcements for their version 0.2 on the list archive are not
>> quite enough to advertise them to their users.
>
> I do not think this README nor a mention in the release notes will get
> their attention either, and many people (and packagers) will continue to
> use the stale versions forever until those versions go away.
>
> I would much rather _replace_ them with a README in the long run, and
> people will notice that they are gone, and then use the README to update
> their install procedure.
>
> For 2.0, I am hesitant to do that, though I do not have a problem with a
> README like this as a heads-up to prepare packagers for the future. I
> say hesitant because people may have been test-packaging 2.0.0-rc3 in
> preparation for release, and it will be annoying to them to suddenly
> switch.

I share the latter two of the above three.  I was giving distro
packagers a bit more credit for their diligence in knowing what they
are packaging than you seem to be in your first point, but I admit
that it is a blind faith.

> But that being said, this is Felipe's code. While we have a legal right
> to distribute it in v2.0, if he would really prefer it out for v2.0, I
> would respect that.

I am fine with that.

> I would prefer to instrument the code with warnings, as that is the sort
> of thing a packager moving from -rc3 to -final might not notice, and
> shipping the warnings to end users who did not package the software in
> the first place will not help them. It is the attention of the packagers
> (and source-builders) you want to get.

I do agree that a new warning every time it is run will be a more
likely to grab users' attention.  The conclusion I draw from that
shared observation is that the user will be annoyed all the time,
without having a power to do anything about the annoyance, until the
report s/he (or other users) Throw at the packager, even when the
version that was packaged hasn't diverged that much yet, which does
not help end users.

I guess the ideal we want is to make sure their build break.  What
if we do the README in addition to rename contrib/remote-helpers to
contrib/obsolete-remote-helpers (or s/obsolete/graduated/)?  It will
give the packagers three choices and I think it hurts people much
less.

 * The packagers that dump the entirety of contrib/ to somewhere
   without doing anything to expose the scripts to user's PATH do
   not have to do anything.  The users who chose to pick them up
   from there notice the missing contrib/remote-helpers, notice
   "obsolete" (or "graduated"), and read README.

 * The packagers that pick up from contrib/remote-helpers and
   arrange the scripts to be on user's PATH will find their build
   broken, because they are no longer where they expect them to be.
   They will notice "obsolete"(or "graduated"), and read README.

   - They can choose to pick them up from "obsolete", perhaps for
     expediency, perhaps for their change aversion, but that will
     not last once we grabbed their attention, and they will switch
     their upstream in some later release once such a choice makes
     them feel dirty enough.

   - They can choose to switch their upstream right now in response
     to the breakage.

I would say that the options I see are these three, and I would rank
the "warn every time" as less helpful to end-users:

 - rename contrib/remote-helpers to contrib/obsolete-remote-helpers
   and add README to point at the upstream.

 - remove contrib/remote-helpers scripts and add README.

 - warn every time the user runs the scripts.

Or am I reacting to a typo and you meant to say "I would prefer not
to instrument"?  Your "shipping the warnings to end users who did
not package the software will not help" was unclear if you meant the
README that has warning or warning message they have to see every
time from the instrumented code.

Re: [PATCH] remote-helpers: point at their upstream repositories

[Felipe Contreras]

Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
> 
> > On Thu, May 15, 2014 at 03:56:29PM -0700, Junio C Hamano wrote:
> >
> >> Two announcements for their version 0.2 on the list archive are not
> >> quite enough to advertise them to their users.
> >
> > I do not think this README nor a mention in the release notes will get
> > their attention either, and many people (and packagers) will continue to
> > use the stale versions forever until those versions go away.
> >
> > I would much rather _replace_ them with a README in the long run, and
> > people will notice that they are gone, and then use the README to update
> > their install procedure.
> >
> > For 2.0, I am hesitant to do that, though I do not have a problem with a
> > README like this as a heads-up to prepare packagers for the future. I
> > say hesitant because people may have been test-packaging 2.0.0-rc3 in
> > preparation for release, and it will be annoying to them to suddenly
> > switch.
> 
> I share the latter two of the above three.  I was giving distro
> packagers a bit more credit for their diligence in knowing what they
> are packaging than you seem to be in your first point, but I admit
> that it is a blind faith.

I don't see why anybody would think otherwise. There are dozens of tools
in contrib/ many without documentation, or even a description of that
whey do. I bet most Git developers don't know what half of them do (even
a quarter), how are package maintainers supposed to know?

All the packages I've seen stash everything into /usr/share/git, with a
few exceptions, like shell completions.

> > But that being said, this is Felipe's code. While we have a legal right
> > to distribute it in v2.0, if he would really prefer it out for v2.0, I
> > would respect that.
> 
> I am fine with that.

Are you? Because in two of the three options you list below you wouldn't
be doing that.

> > I would prefer to instrument the code with warnings, as that is the sort
> > of thing a packager moving from -rc3 to -final might not notice, and
> > shipping the warnings to end users who did not package the software in
> > the first place will not help them. It is the attention of the packagers
> > (and source-builders) you want to get.
> 
> I do agree that a new warning every time it is run will be a more
> likely to grab users' attention.  The conclusion I draw from that
> shared observation is that the user will be annoyed all the time,

That's exactly what we do when anything gets deprecated. Try running Git
with an empty configuration for a day and you'll see tons of warnings,
often huge ones every time the user does common operations, like
`git push`.

Why is it OK to warn about minor behavior changes, but not when the
whole code the user is exercising might be broken?

At least the warning I proposed for the remote-helpers is small and to
the point, unlike the warning of `git push` without refspec.

> without having a power to do anything about the annoyance, until the
> report s/he (or other users) Throw at the packager, even when the
> version that was packaged hasn't diverged that much yet, which does
> not help end users.

What do you expect the packagers are going to do? They will simply
ignore the report as it's not related to their package (git).

I suspect this will continue for quite some time, and very likely these
will not be packaged as part of the official distribution, but some
user-based repository. In some distributions they might end up being
unpackaged completely.

Take git-imerge as an example, a very popular tool you yourself are very
fond of. I don't see it packaged either in ArchLinux, Debian, or Fedora,
and I don't think it will ever be packaged.

So, yes, this will hurt our users, that's what every user of an
out-of-tree tool must suffer, and that's what you unilaterally decided
users of git-remote-hg/bzr should suffer.

> I guess the ideal we want is to make sure their build break.

We cannot make 'cp -r contrib /usr/share/git' fail, that's all packagers
do.

I already pointed to the fact that most of the tools in contrib
shouldn't even be there, and that most of them should have tests. If
there was a standardized way to tests contrib, we could make the build
break. But you ignored my call of attention.

> What if we do the README in addition to rename contrib/remote-helpers
> to contrib/obsolete-remote-helpers (or s/obsolete/graduated/)?  It
> will give the packagers three choices and I think it hurts people much
> less.
> 
>  * The packagers that dump the entirety of contrib/ to somewhere
>    without doing anything to expose the scripts to user's PATH do
>    not have to do anything.  The users who chose to pick them up
>    from there notice the missing contrib/remote-helpers, notice
>    "obsolete" (or "graduated"), and read README.

This is wrong. Users will not notice the missing contrib/remote-helpers.
At least not initially. If they setup links to /usr/share, they'll just
see:

  fatal: Unable to find remote helper for 'hg'

Then they'll see the missing helper, read the README, then report the
problem to the packagers. Then they might include the obsolete
directory, or they might decide not to.

>  * The packagers that pick up from contrib/remote-helpers and
>    arrange the scripts to be on user's PATH will find their build
>    broken, because they are no longer where they expect them to be.
>    They will notice "obsolete"(or "graduated"), and read README.
> 
>    - They can choose to pick them up from "obsolete", perhaps for
>      expediency, perhaps for their change aversion, but that will
>      not last once we grabbed their attention, and they will switch
>      their upstream in some later release once such a choice makes
>      them feel dirty enough.
> 
>    - They can choose to switch their upstream right now in response
>      to the breakage.

That's not how packaging works.

Ask your friend Jonathan Nieder, the packager of Git for Debian, if he
would be interested in maintaining a new git-remote-bzr package. My
guess is that he wont. Maybe he would, but he can assure you that other
packages wont.

The fact of the matter is that users cannot depend on packages any more.
Maybe they'll be packaged, maybe not. If they are it will take a long
time before they do. In the meantime they'll have to manually install
them all all out-of-tree tools.

> I would say that the options I see are these three, and I would rank
> the "warn every time" as less helpful to end-users:
> 
>  - rename contrib/remote-helpers to contrib/obsolete-remote-helpers
>    and add README to point at the upstream.

I don't like this. This would only reward lazy packagers, it wouldn't be
clear to the user what happened at first, and even after they use the
new place, they wouldn't be disserviced by that code.

>  - remove contrib/remote-helpers scripts and add README.

Again, the user will still see an unhelpful message at first. I guess it
wouldn't be as bad as the option 1, but it's not as good as the patch I
proposed where they are replaced with stubs (plus a README).

>  - warn every time the user runs the scripts.

I suggested this, but only as a temporary measure.


I am surprised that we are talking about the ways to proceed, and which
ways would affect the users less, and what would be the repercussions.
In particular, your obvious disconnection from the way packaging is
done, I would venture to say you have never made a package in your life.
The fact that you think packagers of git would simply package
git-remote-hg/bzr as well is pretty appalling. You should have thought
about all this *before* making your stupid decision.

-- 
Felipe Contreras

Re: [PATCH] remote-helpers: point at their upstream repositories

[Jeff King]

On Fri, May 16, 2014 at 09:52:15AM -0700, Junio C Hamano wrote:

> Or am I reacting to a typo and you meant to say "I would prefer not
> to instrument"?  Your "shipping the warnings to end users who did
> not package the software will not help" was unclear if you meant the
> README that has warning or warning message they have to see every
> time from the instrumented code.

Argh, yes, it is a typo. I had written "I would prefer _not_ to
instrument the code with warnings...". While reading it back to myself,
I thought "using underlining there is too argumentative", but somehow
managed to delete the whole word rather than simply the "_" characters.
I'm very sorry to have wasted people's time by accidentally making the
opposite point.

I agree with the line of reasoning you laid out in your email,
especially:

> I would say that the options I see are these three, and I would rank
> the "warn every time" as less helpful to end-users:
> 
>  - rename contrib/remote-helpers to contrib/obsolete-remote-helpers
>    and add README to point at the upstream.
> 
>  - remove contrib/remote-helpers scripts and add README.
> 
>  - warn every time the user runs the scripts.

I hadn't thought of the rename idea, and it would address the concerns I
brought up. I do think "obsolete" is the wrong word, as it sends the
wrong message. The helpers are not obsolete; it is our _copy_ of them
that is.

-Peff

Re: [PATCH] remote-helpers: point at their upstream repositories

[James Denholm]

On Fri, May 16, 2014 at 05:39:42PM -0500, Felipe Contreras wrote:
> (...) I would venture to say you have never made a package in your
> life.

And you have, Felipe? Let us see the years of experience you surely have
in the field.

> The fact that you think packagers of git would simply package
> git-remote-hg/bzr as well is pretty appalling.

It's not an outlandish thought, in fact, I'd suggest it as probable -
provided that they find the projects to be stable and of high quality.
You, or someone else, might have to tap them on the shoulder and play
nice to _ensure_ they know about them (after all, we all know that
packagers _never_ read READMEs, do they), but you're capable of that,
I'm sure.

Re: [PATCH] remote-helpers: point at their upstream repositories

[Felipe Contreras]

James Denholm wrote:
> On Fri, May 16, 2014 at 05:39:42PM -0500, Felipe Contreras wrote:
> > (...) I would venture to say you have never made a package in your
> > life.
> 
> And you have, Felipe? Let us see the years of experience you surely have
> in the field.

As a matter of fact, yes I've written many packages, for Debian, Fedora,
ArchLinux, and others. Even Windows installers.

But that's a red herring. Even if was the worst packager in history,
that doesn't make Junio's decision any more correct.

> > The fact that you think packagers of git would simply package
> > git-remote-hg/bzr as well is pretty appalling.
> 
> It's not an outlandish thought, in fact, I'd suggest it as probable -
> provided that they find the projects to be stable and of high quality.

Do you want to bet?

> You, or someone else, might have to tap them on the shoulder and play
> nice to _ensure_ they know about them (after all, we all know that
> packagers _never_ read READMEs, do they), but you're capable of that,
> I'm sure.

In my experience packagers scratch their own itches, and if
git-remote-hg/bzr are not their itch, I don't see why any amount of
nice poking would make them package them. Some other packager would have
to do it, not the Git packagers.

-- 
Felipe Contreras

Re: [PATCH] remote-helpers: point at their upstream repositories

[Felipe Contreras]

Jeff King wrote:

> I agree with the line of reasoning you laid out in your email,
> especially:

What a shock.

> > I would say that the options I see are these three, and I would rank
> > the "warn every time" as less helpful to end-users:
> > 
> >  - rename contrib/remote-helpers to contrib/obsolete-remote-helpers
> >    and add README to point at the upstream.
> > 
> >  - remove contrib/remote-helpers scripts and add README.
> > 
> >  - warn every time the user runs the scripts.
> 
> I hadn't thought of the rename idea, and it would address the concerns I
> brought up. I do think "obsolete" is the wrong word, as it sends the
> wrong message. The helpers are not obsolete; it is our _copy_ of them
> that is.

Originally you said you would respect if I wanted the code out
for v2.0, I said I would like it out at some point, not necessarily in
v2.0. Junio said he was fine with that, but the proposals above don't do
that.

Now it seems you are changing your mind and you are OK with the code
remaining in.

Do what you will, but I already told you what I will do in response.

-- 
Felipe Contreras

Re: [PATCH] remote-helpers: point at their upstream repositories

[Jeff King]

On Sat, May 17, 2014 at 12:25:30AM -0500, Felipe Contreras wrote:

> > I agree with the line of reasoning you laid out in your email,
> > especially:
> 
> What a shock.

Please stop with these unproductive and rude comments.

> > I hadn't thought of the rename idea, and it would address the concerns I
> > brought up. I do think "obsolete" is the wrong word, as it sends the
> > wrong message. The helpers are not obsolete; it is our _copy_ of them
> > that is.
> 
> Originally you said you would respect if I wanted the code out
> for v2.0, I said I would like it out at some point, not necessarily in
> v2.0. Junio said he was fine with that, but the proposals above don't do
> that.
> 
> Now it seems you are changing your mind and you are OK with the code
> remaining in.

My concerns were with people not noticing the README. Removing the code
entirely is the way I thought of to address that. Junio suggested
another way, which I would also be fine with. And it seems like a
friendlier way than removal to handle it for v2.0, if we are going to
remove the code entirely post-v2.0.

As before, if your desire is to have the code out for v2.0, then say so.
I think we should respect such a request.

-Peff

Re: [PATCH] remote-helpers: point at their upstream repositories

[Felipe Contreras]

Jeff King wrote:
> On Sat, May 17, 2014 at 12:25:30AM -0500, Felipe Contreras wrote:
> 
> > > I agree with the line of reasoning you laid out in your email,
> > > especially:
> > 
> > What a shock.
> 
> Please stop with these unproductive and rude comments.

I am sorry, but the fact of the matter is that you *always* agree with
Junio.

> > > I hadn't thought of the rename idea, and it would address the concerns I
> > > brought up. I do think "obsolete" is the wrong word, as it sends the
> > > wrong message. The helpers are not obsolete; it is our _copy_ of them
> > > that is.
> > 
> > Originally you said you would respect if I wanted the code out
> > for v2.0, I said I would like it out at some point, not necessarily in
> > v2.0. Junio said he was fine with that, but the proposals above don't do
> > that.
> > 
> > Now it seems you are changing your mind and you are OK with the code
> > remaining in.
> 
> My concerns were with people not noticing the README. Removing the code
> entirely is the way I thought of to address that. Junio suggested
> another way, which I would also be fine with. And it seems like a
> friendlier way than removal to handle it for v2.0, if we are going to
> remove the code entirely post-v2.0.

I don't see what is friendlier about this:

 % sudo pacman -Syu
 % cd ~/dev/my-hg-repo
 % git fetch
 fatal: Unable to find remote helper for 'hg'

The users will scratch their heads, wonder what's going on, investigate
themselves, and eventually they'll have to decide how to fix the issue
properly, and how to report it.

On the other hand:

 % git fetch
 WARNING: git-remote-hg is now maintained independently.
 WARNING: For more information visit https://github.com/felipec/git-remote-hg
 searching for changes
 no changes found

You think that's less friendly?

If you think so, I think you are totally biased towards whatever happens
to be the opinion of one person.

> As before, if your desire is to have the code out for v2.0, then say so.
> I think we should respect such a request.

As I said before, I do not wish the code to be removed for v2.0, I would
like to have only a warning. Either way, do whatever you want for v2.0,
it's your users you are hurting.

But if I do not hear *from Junio* that the code will be removed entirely
post-v2.0, hopefully replaced with stubs (which is obviously the most
user-friendly thing to do), I'll do what I said I'll do.

-- 
Felipe Contreras

Re: [PATCH] remote-helpers: point at their upstream repositories

[James Denholm]

Felipe Contreras wrote:
> James Denholm wrote:
> > On Fri, May 16, 2014 at 05:39:42PM -0500, Felipe Contreras wrote:
> > > (...) I would venture to say you have never made a package in your
> > > life.
> > 
> > And you have, Felipe? Let us see the years of experience you surely have
> > in the field.
> 
> As a matter of fact, yes I've written many packages, for Debian, Fedora,
> ArchLinux, and others. Even Windows installers.

I'd hardly say that a few PKGBUILDs count. I've written some myself, not
hard to do.

That said, if I had realised you were going to discuss such a trivial
thing - _making_ packages rather than _maintaining_ them in a repo - I'd
have dismissed your statement as mere idiotic vitriol.

Do you honestly think that Junio has _never made a package?_ Never, on
any of the systems he's ever touched, run makepkg or debuild or
whathaveyou?

I could be wrong here, but I'm fairly sure that Junio is a *nix software
developer of some kind or another. You know, given that he's the
maintainer of git, kinda might be the case. And I really doubt that any
*nix dev, _anywhere_, could have _any_ sort of success without looking
sideways once or twice at a package builder, given that pre-release
homebrewing of expected packages is only an absolutely critical part of
testing.

Come on, man. Don't be silly.

> But that's a red herring. Even if was the worst packager in history,
> that doesn't make Junio's decision any more correct.

No, but it would render your bizarre, tantrum-like accusations as
generally baseless. I mean, I don't think anyone actually puts weight on
them anyway, but hey, never hurts to shine a spotlight on nonsense.

> > > The fact that you think packagers of git would simply package
> > > git-remote-hg/bzr as well is pretty appalling.
> > 
> > It's not an outlandish thought, in fact, I'd suggest it as probable -
> > provided that they find the projects to be stable and of high quality.
> 
> Do you want to bet?

Not a betting man. However, ignoring that for a moment, I doubt we'd be
able to agree on checks and balances for the case where
git-remote-hg/bzr were rejected due to the code being of poor quality or
unstable. So no, I won't bet, because you hold your own work and
opinions as sacrosanct and infallible.

> > You, or someone else, might have to tap them on the shoulder and play
> > nice to _ensure_ they know about them (after all, we all know that
> > packagers _never_ read READMEs, do they), but you're capable of that,
> > I'm sure.
> 
> In my experience packagers scratch their own itches, and if
> git-remote-hg/bzr are not their itch, I don't see why any amount of
> nice poking would make them package them. Some other packager would have
> to do it, not the Git packagers.

If there's a demand, Felipe, and the build process is sane, I can't see
why they wouldn't. Package maintainers are aware they provide a service
to their distributions. If you really want, poke them _with_ the
majority of the necessary work done, hand them the
PKGBUILDs/whathaveyou yourself. Pre-scratch the itch if you really feel
they won't care.

Re: [PATCH] remote-helpers: point at their upstream repositories

[Felipe Contreras]

James Denholm wrote:
> Felipe Contreras wrote:
> > James Denholm wrote:
> > > On Fri, May 16, 2014 at 05:39:42PM -0500, Felipe Contreras wrote:
> > > > (...) I would venture to say you have never made a package in your
> > > > life.
> > > 
> > > And you have, Felipe? Let us see the years of experience you surely have
> > > in the field.
> > 
> > As a matter of fact, yes I've written many packages, for Debian, Fedora,
> > ArchLinux, and others. Even Windows installers.
> 
> I'd hardly say that a few PKGBUILDs count. I've written some myself, not
> hard to do.

Not hard, but Junio clearly hasn't done so.

> That said, if I had realised you were going to discuss such a trivial
> thing - _making_ packages rather than _maintaining_ them in a repo - I'd
> have dismissed your statement as mere idiotic vitriol.

Why would anybody write packages and not maintain them? Of course I'm
talking about maintaining packages.

> Do you honestly think that Junio has _never made a package?_ Never, on
> any of the systems he's ever touched, run makepkg or debuild or
> whathaveyou?

I didn't say _build_ a package, I said _write_ a package. And of course
I mean a significant package, that other people use, and as such needs
to have some maintenance.

> I could be wrong here, but I'm fairly sure that Junio is a *nix software
> developer of some kind or another. You know, given that he's the
> maintainer of git, kinda might be the case. And I really doubt that any
> *nix dev, _anywhere_, could have _any_ sort of success without looking
> sideways once or twice at a package builder, given that pre-release
> homebrewing of expected packages is only an absolutely critical part of
> testing.
> 
> Come on, man. Don't be silly.

You are the one being silly, looking at a package builder doesn't give
you any insight about the way packaging is done in distributions. If
Junio has or hasn't done so is totally unimportant.

You are just talking about completely irrelevant stuff, so I'm going to
ignore your points about the matter.

> > But that's a red herring. Even if was the worst packager in history,
> > that doesn't make Junio's decision any more correct.
> 
> No, but it would render your bizarre, tantrum-like accusations as
> generally baseless. I mean, I don't think anyone actually puts weight on
> them anyway, but hey, never hurts to shine a spotlight on nonsense.
> 
> > > > The fact that you think packagers of git would simply package
> > > > git-remote-hg/bzr as well is pretty appalling.
> > > 
> > > It's not an outlandish thought, in fact, I'd suggest it as probable -
> > > provided that they find the projects to be stable and of high quality.
> > 
> > Do you want to bet?
> 
> Not a betting man. However, ignoring that for a moment, I doubt we'd be
> able to agree on checks and balances for the case where
> git-remote-hg/bzr were rejected due to the code being of poor quality or
> unstable. So no, I won't bet, because you hold your own work and
> opinions as sacrosanct and infallible.

It is not poor quality or unstable, Junio said so himself when he
graduated them to the core.

I suppose you don't trust Junio's opinion either.

> > > You, or someone else, might have to tap them on the shoulder and play
> > > nice to _ensure_ they know about them (after all, we all know that
> > > packagers _never_ read READMEs, do they), but you're capable of that,
> > > I'm sure.
> > 
> > In my experience packagers scratch their own itches, and if
> > git-remote-hg/bzr are not their itch, I don't see why any amount of
> > nice poking would make them package them. Some other packager would have
> > to do it, not the Git packagers.
> 
> If there's a demand, Felipe, and the build process is sane, I can't see
> why they wouldn't.

Your failure of foresight doesn't change what will actually happen in
the future.

Moreover, your argument that follows is a straw man, I argued that the
original maintainer of the "git" package wouldn't do the "git-remote-hg"
package, you didn't address that at all.

-- 
Felipe Contreras

Re: [PATCH] remote-helpers: point at their upstream repositories

[Matthieu Moy]

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

>  % git fetch
>  WARNING: git-remote-hg is now maintained independently.
>  WARNING: For more information visit https://github.com/felipec/git-remote-hg
>  searching for changes
>  no changes found

I don't think the situation is as simple as you claim. In many cases,
the first step before the ones you are mentionning are:

  cd $git/contrib/remote-helpers
  cp git-remote-{hg,bzr} somewhere/in/path

They produces no warning if git-remote-{hg,bzr} exist with the warning,
but "no such file or directory: contrib/remote-helpers" if the directory
has been renamed or removed.

When git-remote-{hg,bzr} are installed with a package manager, the fact
that they are part of Git's core or not is often irrelevant. For
example, Debian splits the git.git source into many packages, so a
Debian user will not see any difference between helpers included in
git.git or outside (e.g. I have to install the package git-svn if I want
to use git-svn).

That said, I'm fine with the "add a warning" option too.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [PATCH] remote-helpers: point at their upstream repositories

[Felipe Contreras]

Matthieu Moy wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> >  % git fetch
> >  WARNING: git-remote-hg is now maintained independently.
> >  WARNING: For more information visit https://github.com/felipec/git-remote-hg
> >  searching for changes
> >  no changes found
> 
> I don't think the situation is as simple as you claim. In many cases,
> the first step before the ones you are mentionning are:
> 
>   cd $git/contrib/remote-helpers
>   cp git-remote-{hg,bzr} somewhere/in/path

In many cases, but not all cases. In other cases they are:

    ln -s $git/contrib/remote-helpers/git-remote-hg \
        somewhere/in/path/git-remote-hg

Which has to be done only once, and not every time Git is updated.

> They produces no warning if git-remote-{hg,bzr} exist with the warning,
> but "no such file or directory: contrib/remote-helpers" if the directory
> has been renamed or removed.

So? They'll get the warning the next time they try to use it, and their
workflow won't be interrupted, and the warning will be more useful than
"No such file or directory".

> When git-remote-{hg,bzr} are installed with a package manager, the fact
> that they are part of Git's core or not is often irrelevant. For
> example, Debian splits the git.git source into many packages, so a
> Debian user will not see any difference between helpers included in
> git.git or outside (e.g. I have to install the package git-svn if I want
> to use git-svn).

Yet there is no git-hg. And I doubt Jonathan Nieder is going to package
the out-of-tree git-bzr, which as far as I know, is the only out-of-tree
package of these remote helpers in any distro.

-- 
Felipe Contreras

Re: [PATCH] remote-helpers: point at their upstream repositories

[Junio C Hamano]

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

>> > But that being said, this is Felipe's code. While we have a legal right
>> > to distribute it in v2.0, if he would really prefer it out for v2.0, I
>> > would respect that.
>> 
>> I am fine with that.
>
> Are you? Because in two of the three options you list below you wouldn't
> be doing that.

"that" does not refer to "remove them at v2.0 (unconditional)".  It
refers to "If Felipe really wants for the removal for v2.0, I would
respect that".  And I saw you said you did not want to disrupt v2.0.

If the options I listed all meant removal at v2.0, then I would
understand your complaints, but that is not the case, so I am not
sure what to make of that.

> The fact of the matter is that users cannot depend on packages any more.
> Maybe they'll be packaged, maybe not. If they are it will take a long
> time before they do. In the meantime they'll have to manually install
> them all all out-of-tree tools.

I have always thought that distro packagers are the biggest ally us
project leaders have.  They locate useful pieces of software,
massage them into a shape that fit their distro well and deliver
what we write to their audience.  Packaging stuff that are useful to
their end-users is what they do best, and not leaving useful stuff
unpackaged is in their best interest.

Your statement makes it sound like they are incompetent lazy fools
who do not know what is useful for their users.

I find it disturbing to see such a distrust.  Or am I being too
naive to have too much faith in packaging folks?

I checked the list of packages that depend on "git" on one of my
boxes (it is a bit old Ubuntu).  I of course expected that many of
them are what comes from our tree split into their own "niche tool"
packages (e.g. git-svn, git-gui, gitweb...), but I was pleasantly
surprised to see many that I haven't even aware of being packaged.
Of course, "tig" is among the packages that depend on us which I am
happy to see.

There are things of somewhat questionable value I saw in the list,
of course.  It is already 2014, and I feel fairly safe to feel that
I can say without offending too many people that I doubt "git-arch"
would be on such a list of packages distros offer to their users, if
it were written as a third-party plug-in today.

It is an (odd) example of a package that is still there mostly by
inertia at this point, and that inertia comes from many things.  It
is in our tree outside contrib/, it was found useful once in the
past and was packaged, the packager already has infrastructure to
cut a separate package out of our tree, and it is more trouble to
retire it and risk breaking minority users than just keep shipping
it.

But hg is not in a situation similar to tla, is it?  I simply cannot
imagine "there is no history worthwhile to salvage out of Mercurial
repositories" coming anytime in the near future.

After looking at the reverse-depends list of packages, my faith is
strengthened in that the Git ecosystem is truly maturing and useful
third-party plug-ins will be picked up by distro packagers.

Am I delusional?

Re: [PATCH] remote-helpers: point at their upstream repositories

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> My concerns were with people not noticing the README. Removing the code
> entirely is the way I thought of to address that. Junio suggested
> another way, which I would also be fine with. And it seems like a
> friendlier way than removal to handle it for v2.0, if we are going to
> remove the code entirely post-v2.0.
>
> As before, if your desire is to have the code out for v2.0, then say so.
> I think we should respect such a request.

OK.  After thinking about it a bit more, I think renaming the
directory at this point is not a "clearly superiour" option and the
judgment largely depends on your philosophy on transition.  Let me
explain, backwards from the desired endgame.

I think all of us (including Felipe) agree that in some future time
[*1*], we won't have either of these two scripts in contrib/, but
just like contrib/vim, we will leave a README to help those who read
a stale page on the Web that says "remote-hg in contrib/ is the
officially recommended tool to interact with Mercurial".  The README
will tell them that they read a stale page that is no longer true,
and direct them to where they can grab remote-hg/bzr.

We will need to keep contrib/remote-helpers in that endgame state
for quite some time.

If a user of 1.9.x updates to such an endgame version and then runs
the same fetch from Hg, he will not just notice the breakage but is
forced at that point to go to the GitHub URL and switch, but it may
not be a convenient time for him to go through that process.  To
help these users, a step that ships the "stale but working" scripts
that give warning is necessary before the endgame state, and
Felipe's 77621193 (contrib: remote-helpers: add move warnings
(v2.0), 2014-05-13) is such a change.

My suggestion to rename the directory without smudging the scripts
was meant to be a step that can come before that step, and I think
its necessity is debatable.  It depends on how gradual a transition
you want to give, and being always the more cautious type, I think
having such a step will give packagers who pay attention to what
they package and users who pay attention to what they install
without packaging an early chance to notice and prepare.

 - The endgame will force the user to update at the point when the
   user needs to use it for his real work, when he may not have time
   for sysadmin. 

 - The "always warn" does not force update at the point of use, but
   it still does not help them to notice well before they try to use
   it for the first time after update;

 - "Break the build" attempts to help them notice when they try to
   update, not when they need to use the updated one right at this
   moment.

But I am fine with an expedited transition schedule without the
"break the build" step.  That was an optional first step, because
"warn but still work" state we must have before the endgame will
give the users the choice of when to adjust anyway.

I also thought about adding an extra step to have even more gradual
transition, by the way.  A step before the endgame will ship these
scripts without anything but "instruct and fail" (this is not "warn
and fail", as it is too late "warn", as the scripts are crippled not
to work at this point).

That will still force the user to update at the point when the user
needs to use it, but seeing the instruction (e.g. "run this curl
command to fetch from this URL and store it in a file called
git-remote-xx on your $PATH") that is easy to follow immediately
would be better than seeing only a failure (i.e. "remote-hg not
found"), having to go fish the README, visiting the GitHub pages
and figuring out how to fetch and install the script, which would
be what the user will get with "README only, no scripts" endgame.

For that matter, the warning message given by 77621193, also README
added by f000c4e6 (remote-helpers: point at their upstream
repositories, 2014-05-15) may want to mention not just the GitHub
URL for the repository as the whole, but the URL to fetch the latest
blob with curl/wget, if we really want to help users go back to
their tasks at hand with minimum interruption.  I know how to
construct a URL to follow the tip of a specific branch and obtain a
full .zip from a GitHub repository, but I do not know offhand if you
can do the same for a single blob.  If we can come up with one, we
should add such a instruction to the warning message and README, as
that instruction will be the only thing to help the users in the
endgame state anyway.

So to summarize, the following timeline is a full possibility:

  1. (optional) break the build by renaming directory and add
     README. Include not just the repository URL but a blob URL
     and instruction to download via wget/curl.

  2. add warning that is given every time the scripts are run and
     give the same instruction as in README.

  3. (optional) cripple the script to make them always fail after
     showing the same warning as above.

  4. Keep README and retire everything else.

but I am perfectly fine with dropping these two optional steps and
follow an expedited transition of doing 2 and 4.


[Footnotes]

*1* Largely of Felipe's choice, and we also agree that that future
    time is not 2.0, as Felipe says he does not want to disrupt the
    upcoming release, and neither do we.

Re: [PATCH] remote-helpers: point at their upstream repositories

[Felipe Contreras]

Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> >> > But that being said, this is Felipe's code. While we have a legal right
> >> > to distribute it in v2.0, if he would really prefer it out for v2.0, I
> >> > would respect that.
> >> 
> >> I am fine with that.
> >
> > Are you? Because in two of the three options you list below you wouldn't
> > be doing that.
> 
> "that" does not refer to "remove them at v2.0 (unconditional)".  It
> refers to "If Felipe really wants for the removal for v2.0, I would
> respect that".  And I saw you said you did not want to disrupt v2.0.
> 
> If the options I listed all meant removal at v2.0, then I would
> understand your complaints, but that is not the case, so I am not
> sure what to make of that.

It is a weird choice of semantics then. You said you would "respect" my
wish, but your proposals did not "follow" my wish.

> > The fact of the matter is that users cannot depend on packages any more.
> > Maybe they'll be packaged, maybe not. If they are it will take a long
> > time before they do. In the meantime they'll have to manually install
> > them all all out-of-tree tools.
> 
> I have always thought that distro packagers are the biggest ally us
> project leaders have.  They locate useful pieces of software,
> massage them into a shape that fit their distro well and deliver
> what we write to their audience.  Packaging stuff that are useful to
> their end-users is what they do best, and not leaving useful stuff
> unpackaged is in their best interest.

Yet I bet a lot of open-source software is not actually packaged. That's
the reason there's Python's pip, and Ruby gems.

*If* your software is popular enough, then yes, packagers are your
biggest allys, but if not, they aren't.

> Your statement makes it sound like they are incompetent lazy fools
> who do not know what is useful for their users.

This sentence proves you have no idea how packaging is done.

There is no comittee that hunts down packages that are "useful for their
users" and assigns available packagers to those projects. Exactly the
same way you don't assign Git developers tasks based on what is "useful
for our users".

Each packager decides what project they package, just like every Git
developer decides on what feature they work on.

An obscure package might be packaged because a prominent Debian package
maintainer likes it, and a much more useful and popular project might
not be packaged simply because no package maintainer is interested in
it.

Exactly the same happens in Git; people work on relatively obsucre
features such as ref transactions, because they are interested in them,
and features much more "useful for our" users get ignored, because
there's nobody (of relevance) championing them.

When a popular project that is "useful for the users" is neglected for
too long, what usually happens is that an outsider steps up and does the
packaging, which then goes through a review process, and that outsider
might become an official maintainer, and maybe start to package other
things too. That's how packagers join the project.

But nothing gets done if no ousider steps up.

Excatly the same happens in Git; when a feature has been neglected for
too long, an outsider comes and tries to implement it, go through a
review process, and eventually start fixing other things too.

So no, there's no comittee that decides what should be packaged, just
like there's no committe that decides what Git features should be
developed.

It's incredibly alarming that you would think packagers in open source
distributions would work any other way.

And it's incredibly funny that you would label people working on such
model as "incompetent lazy fools" for "not knowing what is useful for
their users", when it is *EXACTLY* the same thing you do in Git; you do
not know what is useful for our users; you don't actually care; you just
work on whatever you like to work on.

It's even worst than that, because if somebody steps up to package a
popular project, the package goes in, but when somebody steps up to
implement a feature that improves our user-interface in Git; they get
their knees shot.

> I find it disturbing to see such a distrust.  Or am I being too
> naive to have too much faith in packaging folks?

There is so much wrong with your mode of thinking and the blindness that
you don't see what you yourself do that I don't even know where to
begin.

Yes you are too naive, on many levels.

> I checked the list of packages that depend on "git" on one of my
> boxes (it is a bit old Ubuntu).  I of course expected that many of
> them are what comes from our tree split into their own "niche tool"
> packages (e.g. git-svn, git-gui, gitweb...), but I was pleasantly
> surprised to see many that I haven't even aware of being packaged.
> Of course, "tig" is among the packages that depend on us which I am
> happy to see.
> 
> There are things of somewhat questionable value I saw in the list,
> of course.  It is already 2014, and I feel fairly safe to feel that
> I can say without offending too many people that I doubt "git-arch"
> would be on such a list of packages distros offer to their users, if
> it were written as a third-party plug-in today.
> 
> It is an (odd) example of a package that is still there mostly by
> inertia at this point, and that inertia comes from many things.  It
> is in our tree outside contrib/, it was found useful once in the
> past and was packaged, the packager already has infrastructure to
> cut a separate package out of our tree, and it is more trouble to
> retire it and risk breaking minority users than just keep shipping
> it.
> 
> But hg is not in a situation similar to tla, is it?  I simply cannot
> imagine "there is no history worthwhile to salvage out of Mercurial
> repositories" coming anytime in the near future.
> 
> After looking at the reverse-depends list of packages, my faith is
> strengthened in that the Git ecosystem is truly maturing and useful
> third-party plug-ins will be picked up by distro packagers.

Where is git-imerge packaged?

Do you want to bet? Nah, you don't *ever* want to accept you were wrong,
even you clearly where.

> Am I delusional?

Yes you are.

This is what's going to happen: there won't be an official git-hg
package for *years*, if there is ever one. That is my prediction based
on all the available evidence, I am willing to stand by it and accept I
was wrong if it proves otherwise.

Are you willing to stand by your own decisions?

-- 
Felipe Contreras

Re: [PATCH] remote-helpers: point at their upstream repositories

[Felipe Contreras]

Junio C Hamano wrote:
> My suggestion to rename the directory without smudging the scripts
> was meant to be a step that can come before that step, and I think
> its necessity is debatable.  It depends on how gradual a transition
> you want to give, and being always the more cautious type,

> I think having such a step will give packagers who pay attention to
> what they package and users who pay attention to what they install
> without packaging an early chance to notice and prepare.

Immaginary packagers.

>  - The "always warn" does not force update at the point of use, but
>    it still does not help them to notice well before they try to use
>    it for the first time after update;

I don't understand this sentence. They will see a big fat warning every
time they run the tool, of course they'll notice.

>  - "Break the build" attempts to help them notice when they try to
>    update, not when they need to use the updated one right at this
>    moment.

This cannot be done.

> But I am fine with an expedited transition schedule without the
> "break the build" step.  That was an optional first step, because
> "warn but still work" state we must have before the endgame will
> give the users the choice of when to adjust anyway.
> 
> I also thought about adding an extra step to have even more gradual
> transition, by the way.  A step before the endgame will ship these
> scripts without anything but "instruct and fail" (this is not "warn
> and fail", as it is too late "warn", as the scripts are crippled not
> to work at this point).
> 
> That will still force the user to update at the point when the user
> needs to use it, but seeing the instruction (e.g. "run this curl
> command to fetch from this URL and store it in a file called
> git-remote-xx on your $PATH") that is easy to follow immediately
> would be better than seeing only a failure (i.e. "remote-hg not
> found"), having to go fish the README, visiting the GitHub pages
> and figuring out how to fetch and install the script, which would
> be what the user will get with "README only, no scripts" endgame.

I don't see what's so complicated about this:

  WARNING: git-remote-hg is now maintained independently.
  WARNING: For more information visit https://github.com/felipec/git-remote-hg

They click that URL, and the are immediately greated with this:

  To enable this, simply add the git-remote-hg script anywhere in your $PATH:

    wget https://raw.github.com/felipec/git-remote-hg/master/git-remote-hg -O ~/bin/git-remote-hg
    chmod +x ~/bin/git-remote-hg

Clearly you haven't even bothered to visit the home pages of the
projects you threw to the wolves.

> So to summarize, the following timeline is a full possibility:
> 
>   1. (optional) break the build by renaming directory and add
>      README. Include not just the repository URL but a blob URL
>      and instruction to download via wget/curl.

That won't break the build.

>   2. add warning that is given every time the scripts are run and
>      give the same instruction as in README.
> 
>   3. (optional) cripple the script to make them always fail after
>      showing the same warning as above.

This is what I want, and I already sent the patches for; the scripts
will be stubs. At this point you would have effectively removed the
code, which what I want.
 
>   4. Keep README and retire everything else.

After you've removed the code, I don't care what you do, but I'd say you
should remove the stubs after a long period of time.

-- 
Felipe Contreras

Re: [PATCH] remote-helpers: point at their upstream repositories

[Junio C Hamano]

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

> Junio C Hamano wrote:
>
>>  - The "always warn" does not force update at the point of use, but
>>    it still does not help them to notice well before they try to use
>>    it for the first time after update;
>
> I don't understand this sentence. They will see a big fat warning every
> time they run the tool, of course they'll notice.

Let me ask one question first, in order to avoid miscommunication,
as I really want to get the first step for v2.0-rc4 in a concrete
shape tomorrow.  Do you think gradual transition worth pursuing or
do you think it is a waste of time?

I do not think it matters that much, but since you said you do not
understand...

What I meant was that when they update their Git (perhaps at the
beginning of the week), the won't know they will now be running
stale code.  The warning comes only when they first run it (perhaps
at the end of the week) to do some real work with a remote hg
repository, which may not be a convenient time to do their sysadmin
task.  And the next time when they update their Git, they may have
already forgotten about the warning.  The ideal transition would be
to somehow let them notice when they are in sysadmin mode.

>>  - "Break the build" attempts to help them notice when they try to
>>    update, not when they need to use the updated one right at this
>>    moment.
>
> This cannot be done.

Renaming the directory will not "break at the build time" for those
who have already did "ln -s" these scripts, of course, but it will
"break at the build time" for others (i.e. those who "cp"), no?
Again, not very important, as I too consider it optional.  If you
are shooting for an expedited transition, it is perfectly fine to
drop it.

> They click that URL, and the are immediately greated with this:
>
>   To enable this, simply add the git-remote-hg script anywhere in your $PATH:
>
>     wget https://raw.github.com/felipec/git-remote-hg/master/git-remote-hg -O ~/bin/git-remote-hg
>     chmod +x ~/bin/git-remote-hg

Perfect.  I did check the page when double-checking the URL while
writing the README thing, and I did skim the page, but I must have
missed it.

We could add these two to the warning, then, to discourage people
who see "please visit this URL" and say "Yuck, I have no time for
that" without actually visiting.

>> So to summarize, the following timeline is a full possibility:
>> ...
>>   2. add warning that is given every time the scripts are run and
>>      give the same instruction as in README.
>> 
>>   3. (optional) cripple the script to make them always fail after
>>      showing the same warning as above.
>
> This is what I want, and I already sent the patches for; the scripts
> will be stubs. At this point you would have effectively removed the
> code, which what I want.

I think explained why the step 3 would not help very much compared
to the "there is no script, only README remains" endgame (and that
is why it is marked as "optional").  Actually, you reminded me that
a very short and easy-to-follow instruction is on the page referred
to from README and the warnings, which means that this step would
make even less difference compared to the endgame.

I don't think I saw you explain why that is not the case and why we
do want this step (and I cannot quite tell if you are aiming for
more gradual transition that wants this step, or an expedited one
that does not).  I am fine with either way.

In any case, I'd ask another question to avoid wasting time on
miscommunication.  By "This is what I want", do you mean you want
this step 3 also in v2.0, or do you mean you want 2 alone in v2.0
then step 3 some time later?

Unless you want 2 and 3 together at v2.0, we do not have to decide
the merit of step 3 before v2.0-rc4; if you do want 2 and 3 together
for v2.0, then your prompt answer matters a lot.

You said your "wish" wasn't "respected" in another message, when I
explained that I thought you did not want to disrupt v2.0 by
insisting on removing these scripts and that was why I listed
options that did not involve removal of the scripts.  Are you saying
that you wish you want to see them removed or crippled at v2.0?
Changing your mind after discussion is perfectly fine, by the way.

Thanks.

Re: [PATCH] remote-helpers: point at their upstream repositories

[Junio C Hamano]

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

> Junio C Hamano wrote:
>
>>   2. add warning that is given every time the scripts are run and
>>      give the same instruction as in README.
>> 
>>   3. (optional) cripple the script to make them always fail after
>>      showing the same warning as above.
>
> This is what I want, and I already sent the patches for; the scripts
> will be stubs. At this point you would have effectively removed the
> code, which what I want.
>  
>>   4. Keep README and retire everything else.
>
> After you've removed the code, I don't care what you do, but I'd say you
> should remove the stubs after a long period of time.

Let's try this in a different way, as I sense there is a
misunderstanding somewhere about your "wish".

>> "that" does not refer to "remove them at v2.0 (unconditional)".  It
>> refers to "If Felipe really wants for the removal for v2.0, I would
>> respect that".  And I saw you said you did not want to disrupt v2.0.
>> 
>> If the options I listed all meant removal at v2.0, then I would
>> understand your complaints, but that is not the case, so I am not
>> sure what to make of that.
>
> It is a weird choice of semantics then. You said you would "respect" my
> wish, but your proposals did not "follow" my wish.

I understand you do not want to disrupt v2.0.  My assumption of that
"not disrupting v2.0" has been "there still are git-remote-{hg,bzr}
that work just like what they had in v1.9.x, perhaps with some
enhancements and regressions you added in the meantime", and I
understood Peff's comment "If Felipe wants the removal" to mean that
kind of "disruption", i.e. "there is no git-remote-{hg,bzr} that
work.", which would be either step 3 or 4.

But your "After you've removed the code" comment above makes me
wonder that perhaps your definition of "not disrupting" was
different from ours (which is not good or bad, just different) and
you consider that step 3. is "removal but not distupting v2.0"?

If that is what you want in v2.0, then please say so, and I already
said I am fine with that.

Re: [PATCH] remote-helpers: point at their upstream repositories

[Felipe Contreras]

Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> > Junio C Hamano wrote:
> >
> >>  - The "always warn" does not force update at the point of use, but
> >>    it still does not help them to notice well before they try to use
> >>    it for the first time after update;
> >
> > I don't understand this sentence. They will see a big fat warning every
> > time they run the tool, of course they'll notice.
> 
> Let me ask one question first, in order to avoid miscommunication,
> as I really want to get the first step for v2.0-rc4 in a concrete
> shape tomorrow.  Do you think gradual transition worth pursuing or
> do you think it is a waste of time?

If by "gradual transition" you mean place the contrib/remote-helpers in
another directory before removing the code, I do think it's a waste of
time, but I don't really care, as long as eventually stubs are put in
place.

> I do not think it matters that much, but since you said you do not
> understand...
> 
> What I meant was that when they update their Git (perhaps at the
> beginning of the week), the won't know they will now be running
> stale code.  The warning comes only when they first run it (perhaps
> at the end of the week) to do some real work with a remote hg
> repository, which may not be a convenient time to do their sysadmin
> task.  And the next time when they update their Git, they may have
> already forgotten about the warning.  The ideal transition would be
> to somehow let them notice when they are in sysadmin mode.

You can add such change in the release notes. Other than that I don't
see what we could do.

> >>  - "Break the build" attempts to help them notice when they try to
> >>    update, not when they need to use the updated one right at this
> >>    moment.
> >
> > This cannot be done.
> 
> Renaming the directory will not "break at the build time" for those
> who have already did "ln -s" these scripts, of course, but it will
> "break at the build time" for others (i.e. those who "cp"), no?

How many people copy the scripts every time they update Git? Not many
I'd gather.

> > They click that URL, and the are immediately greated with this:
> >
> >   To enable this, simply add the git-remote-hg script anywhere in your $PATH:
> >
> >     wget https://raw.github.com/felipec/git-remote-hg/master/git-remote-hg -O ~/bin/git-remote-hg
> >     chmod +x ~/bin/git-remote-hg
> 
> Perfect.  I did check the page when double-checking the URL while
> writing the README thing, and I did skim the page, but I must have
> missed it.
> 
> We could add these two to the warning, then, to discourage people
> who see "please visit this URL" and say "Yuck, I have no time for
> that" without actually visiting.

We could. Personally I don't see the point of making the warning any
more annoying. The instructiosn are just one click away, and if they
have no time for that, they can just ignore the warning.

> >> So to summarize, the following timeline is a full possibility:
> >> ...
> >>   2. add warning that is given every time the scripts are run and
> >>      give the same instruction as in README.
> >> 
> >>   3. (optional) cripple the script to make them always fail after
> >>      showing the same warning as above.
> >
> > This is what I want, and I already sent the patches for; the scripts
> > will be stubs. At this point you would have effectively removed the
> > code, which what I want.
> 
> I think explained why the step 3 would not help very much compared
> to the "there is no script, only README remains" endgame (and that
> is why it is marked as "optional").  Actually, you reminded me that
> a very short and easy-to-follow instruction is on the page referred
> to from README and the warnings, which means that this step would
> make even less difference compared to the endgame.
> 
> I don't think I saw you explain why that is not the case and why we
> do want this step (and I cannot quite tell if you are aiming for
> more gradual transition that wants this step, or an expedited one
> that does not).  I am fine with either way.

To me the endgame is that the code is removed, and only stubs remain.
What you do after that is up to you.

> In any case, I'd ask another question to avoid wasting time on
> miscommunication.  By "This is what I want", do you mean you want
> this step 3 also in v2.0, or do you mean you want 2 alone in v2.0
> then step 3 some time later?

I meant I want 3. eventually, hopefully for v2.1.

> You said your "wish" wasn't "respected" in another message, when I
> explained that I thought you did not want to disrupt v2.0 by
> insisting on removing these scripts and that was why I listed
> options that did not involve removal of the scripts.  Are you saying
> that you wish you want to see them removed or crippled at v2.0?
> Changing your mind after discussion is perfectly fine, by the way.

You did not specify those were only for v2.0.

No, I don't want them crippled for v2.0. A warning should suffice.

-- 
Felipe Contreras

Re: [PATCH] remote-helpers: point at their upstream repositories

[Junio C Hamano]

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

> Junio C Hamano wrote:
>> 
>> After looking at the reverse-depends list of packages, my faith is
>> strengthened in that the Git ecosystem is truly maturing and useful
>> third-party plug-ins will be picked up by distro packagers.
>
> Where is git-imerge packaged?

I didn't see it on the archive the said Ubuntu box slurps from, but
I did not check all the other distros.

Michael, do you know what distro folks are doing with imerge?  For
the purpose of this thread, "I do not follow distros, and I do not
know" is a perfectly acceptable answer, but it would be very
relevant if your answer is "I suggested these distros to include it,
but so far they have been uncooperative and I haven't had much
success".

> Do you want to bet? Nah, you don't *ever* want to accept you were wrong,
> even you clearly where.
> ...
> This is what's going to happen: there won't be an official git-hg
> package for *years*, if there is ever one. That is my prediction based
> on all the available evidence, I am willing to stand by it and accept I
> was wrong if it proves otherwise.
>
> Are you willing to stand by your own decisions?

If I understand correctly, you have made and you do maintain some
packages and as an insider, you do not have to wait for "an
outsider" to step up to make remote-{hg,bzr} packages yourself.  You
may already have done so for your own use and told other people
about them, and others may have chosen to wait for you to push them
to distros instead of championing these tools by packaging them
themselves.

When you have such an influence on the outcome either way of your
choice, I do not see much value in such a bet.

I do know enough to agree with you that there may be no committee,
packagers may scratch their own itches, and a program that is not
very useful for the packagers, especially the ones useful only for
non-technical niche audiences, may fall through the cracks.

But I actually think that "we package what we want to use" is a good
thing for programs whose primary audience is the software developer
types.  The packagers are part of their audiences [*1*].  Because of
that, even if remote-{hg,bzr} do not get packaged for a long time, I
doubt that it tells us what you are stipulating.  The only thing we
can infer would be that these programs did not interest the software
developer types to motivate them enough, and we wouldn't know why
they found the programs uninteresting.  It may be because those who
have history in Hg prefer to interact with remote Git repositories
by pushing into and fetching from them using Hg tools than using Git
tools.  It would not indicate "useful tools fall through the cracks"
if it were the case, would it?

Indeed I saw bzr-git that came from the Bazaar land packaged on the
box I mentioned, and its description sounded like it is meant to
work in such a way that allows Bazaar commits to be pushed to Git
repositories using a bzr tool.

By the way, I also saw git-mediawiki packaged from contrib/ in our
tree.  I found it not very credible to say "contrib/ is treated as a
single ball of wax without much value by packagers, and we need to
move the helpers up to core in order for them to be used more
widely" after seeing that.


[Footnotes]

*1* I saw you called them "wolves" at least twice recently---where
    does such a distrust come from?

Re: [PATCH] remote-helpers: point at their upstream repositories

[Junio C Hamano]

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

>> We could add these two to the warning, then, to discourage people
>> who see "please visit this URL" and say "Yuck, I have no time for
>> that" without actually visiting.
>
> We could. Personally I don't see the point of making the warning any
> more annoying. The instructiosn are just one click away, and if they
> have no time for that, they can just ignore the warning.

Yes, if they know a short-and-sweet instruction is at the top of the
page, "just one click away" is a good justification, but the reason
I suggested to add the instruction to the warning is because the URL
alone does not tell them that there is a short and easy-to-follow
instruction is behind it, not giving them enough clue to judge if
they have time for that or not.

> To me the endgame is that the code is removed, and only stubs remain.
> ...
> I meant I want 3. eventually, hopefully for v2.1.
> ...
> No, I don't want them crippled for v2.0. A warning should suffice.

OK, I think I understand what you want, and I am fine with that
timeline.

I can start preparing -rc4 now, but it may slip into tomorrow.

Thanks.

Re: [PATCH] remote-helpers: point at their upstream repositories

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> We could. Personally I don't see the point of making the warning any
>> more annoying....

If we were giving the users a choice of "no thanks, I'll keep using
the obsolete one", then trying to be a low key and giving them a way
to squelch with an advice.* config might make sense, but if we plan
to remove/stub at as early as v2.1, I think annoyance is very much
what we want, actually, because it clearly is the case that we do
prefer users switching instead of waiting for v2.1.

How does this sound?

-- >8 --
From: Junio C Hamano <gitster@pobox.com>
Date: Mon, 19 May 2014 16:05:34 -0700
Subject: [PATCH] remote-helpers: give short instructions to download the
 latest

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 contrib/remote-helpers/git-remote-bzr | 6 ++++++
 contrib/remote-helpers/git-remote-hg  | 6 ++++++
 2 files changed, 12 insertions(+)

diff --git a/contrib/remote-helpers/git-remote-bzr b/contrib/remote-helpers/git-remote-bzr
index be4b9a3..c0cb652 100755
--- a/contrib/remote-helpers/git-remote-bzr
+++ b/contrib/remote-helpers/git-remote-bzr
@@ -46,6 +46,12 @@ import atexit, shutil, hashlib, urlparse, subprocess
 sys.stderr.write('WARNING: git-remote-bzr is now maintained independently.\n')
 sys.stderr.write('WARNING: For more information visit https://github.com/felipec/git-remote-bzr\n')
 
+sys.stderr.write('''WARNING: You can pick a directory on your $PATH and download it, e.g.:
+WARNING:   $ wget -O $HOME/bin/git-remote-bzr \\
+WARNING:     https://raw.github.com/felipec/git-remote-bzr/master/git-remote-bzr
+WARNING:   $ chmod +x $HOME/bin/git-remote-bzr
+''')
+
 NAME_RE = re.compile('^([^<>]+)')
 AUTHOR_RE = re.compile('^([^<>]+?)? ?[<>]([^<>]*)(?:$|>)')
 EMAIL_RE = re.compile(r'([^ \t<>]+@[^ \t<>]+)')
diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg
index 989df66..c07d1a5 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -28,6 +28,12 @@ import time as ptime
 sys.stderr.write('WARNING: git-remote-hg is now maintained independently.\n')
 sys.stderr.write('WARNING: For more information visit https://github.com/felipec/git-remote-hg\n')
 
+sys.stderr.write('''WARNING: You can pick a directory on your $PATH and download it, e.g.:
+WARNING:   $ wget -O $HOME/bin/git-remote-hg \\
+WARNING:     https://raw.github.com/felipec/git-remote-hg/master/git-remote-hg
+WARNING:   $ chmod +x $HOME/bin/git-remote-hg
+''')
+
 #
 # If you want to see Mercurial revisions as Git commit notes:
 # git config core.notesRef refs/notes/hg
-- 
2.0.0-rc3-442-ga28c44b

Re: [PATCH] remote-helpers: point at their upstream repositories

[Felipe Contreras]

Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
> 
> > Felipe Contreras <felipe.contreras@gmail.com> writes:
> >
> >> We could. Personally I don't see the point of making the warning any
> >> more annoying....
> 
> If we were giving the users a choice of "no thanks, I'll keep using
> the obsolete one", then trying to be a low key and giving them a way
> to squelch with an advice.* config might make sense, but if we plan
> to remove/stub at as early as v2.1, I think annoyance is very much
> what we want, actually, because it clearly is the case that we do
> prefer users switching instead of waiting for v2.1.
> 
> How does this sound?

The patch below assumes the user has ~/bin in his PATH, which might not
be the case. Personally I don't see the point of creating extra
annoyance with instructions that might not work.

-- 
Felipe Contreras

Re: [PATCH] remote-helpers: point at their upstream repositories

[Junio C Hamano]

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

> Junio C Hamano wrote:
>> Junio C Hamano <gitster@pobox.com> writes:
>> 
>> > Felipe Contreras <felipe.contreras@gmail.com> writes:
>> >
>> >> We could. Personally I don't see the point of making the warning any
>> >> more annoying....
>> 
>> If we were giving the users a choice of "no thanks, I'll keep using
>> the obsolete one", then trying to be a low key and giving them a way
>> to squelch with an advice.* config might make sense, but if we plan
>> to remove/stub at as early as v2.1, I think annoyance is very much
>> what we want, actually, because it clearly is the case that we do
>> prefer users switching instead of waiting for v2.1.
>> 
>> How does this sound?
>
> The patch below assumes the user has ~/bin in his PATH, which might not
> be the case. Personally I don't see the point of creating extra
> annoyance with instructions that might not work.

Yeah, I would be lying if I said that "that might not work" did not
bother me, but I decided it would be on the good side of the
borderline (it is better to be concise and slightly wrong than
ultra-verbose and precise).  As you may have guessed, they were
stolen from your earlier message that shows what the site says after
all ;-)

I will probably tag -rc4 with the patch applied sometime tomorrow.

Re: [PATCH] remote-helpers: point at their upstream repositories

[Michael Haggerty]

On 05/19/2014 11:31 PM, Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
>> Junio C Hamano wrote:
>>>
>>> After looking at the reverse-depends list of packages, my faith is
>>> strengthened in that the Git ecosystem is truly maturing and useful
>>> third-party plug-ins will be picked up by distro packagers.
>>
>> Where is git-imerge packaged?
> 
> I didn't see it on the archive the said Ubuntu box slurps from, but
> I did not check all the other distros.
> 
> Michael, do you know what distro folks are doing with imerge?  For
> the purpose of this thread, "I do not follow distros, and I do not
> know" is a perfectly acceptable answer, but it would be very
> relevant if your answer is "I suggested these distros to include it,
> but so far they have been uncooperative and I haven't had much
> success".

I haven't heard of any Linux distros that have git-imerge packages.  I
just searched the package archives for Debian, Fedora, Gentoo, and Arch
without finding it.

OTOH I haven't suggested it to any package maintainers nor done much to
promote it after the initial flurry of publicity after GitMerge 2013
(blog posts, talk, and interview on GitMinutes).

Oh yeah, there's also this animated GIF here [1] :-)

Michael

[1] https://github.com/blog/1691-michael-haggerty-is-a-githubber

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/

Re: [PATCH] remote-helpers: point at their upstream repositories

[Johan Herland]

On Tue, May 20, 2014 at 4:55 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> On 05/19/2014 11:31 PM, Junio C Hamano wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>> Where is git-imerge packaged?
>>
>> I didn't see it on the archive the said Ubuntu box slurps from, but
>> I did not check all the other distros.
>>
>> Michael, do you know what distro folks are doing with imerge?  For
>> the purpose of this thread, "I do not follow distros, and I do not
>> know" is a perfectly acceptable answer, but it would be very
>> relevant if your answer is "I suggested these distros to include it,
>> but so far they have been uncooperative and I haven't had much
>> success".
>
> I haven't heard of any Linux distros that have git-imerge packages.  I
> just searched the package archives for Debian, Fedora, Gentoo, and Arch
> without finding it.

FWIW; someone has made an AUR package (a user-contributed Arch package
recipe) for git-imerge:
https://aur.archlinux.org/packages/git-imerge-git/


...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net

Re: [PATCH] remote-helpers: point at their upstream repositories

[Felipe Contreras]

Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> > Junio C Hamano wrote:
> >
> >>   2. add warning that is given every time the scripts are run and
> >>      give the same instruction as in README.
> >> 
> >>   3. (optional) cripple the script to make them always fail after
> >>      showing the same warning as above.
> >
> > This is what I want, and I already sent the patches for; the scripts
> > will be stubs. At this point you would have effectively removed the
> > code, which what I want.
> >  
> >>   4. Keep README and retire everything else.
> >
> > After you've removed the code, I don't care what you do, but I'd say you
> > should remove the stubs after a long period of time.
> 
> Let's try this in a different way, as I sense there is a
> misunderstanding somewhere about your "wish".
> 
> >> "that" does not refer to "remove them at v2.0 (unconditional)".  It
> >> refers to "If Felipe really wants for the removal for v2.0, I would
> >> respect that".  And I saw you said you did not want to disrupt v2.0.
> >> 
> >> If the options I listed all meant removal at v2.0, then I would
> >> understand your complaints, but that is not the case, so I am not
> >> sure what to make of that.
> >
> > It is a weird choice of semantics then. You said you would "respect" my
> > wish, but your proposals did not "follow" my wish.
> 
> I understand you do not want to disrupt v2.0.  My assumption of that
> "not disrupting v2.0" has been "there still are git-remote-{hg,bzr}
> that work just like what they had in v1.9.x, perhaps with some
> enhancements and regressions you added in the meantime", and I
> understood Peff's comment "If Felipe wants the removal" to mean that
> kind of "disruption", i.e. "there is no git-remote-{hg,bzr} that
> work.", which would be either step 3 or 4.
> 
> But your "After you've removed the code" comment above makes me
> wonder that perhaps your definition of "not disrupting" was
> different from ours (which is not good or bad, just different) and
> you consider that step 3. is "removal but not distupting v2.0"?
> 
> If that is what you want in v2.0, then please say so, and I already
> said I am fine with that.

No, I already said I do not want the code removed from v2.0, that's why
I sent patches that simply added a warning, and I specifically said
those were for 2.0.

However, after seeing this commit:

10e1fee (Revert "Merge branch 'fc/transport-helper-sync-error-fix'")

Which is:

 1) Inaccurate
 2) A lie (*you* broke 2.0, not me)
 3) A disservice to users

I therefore change my wish for you to remove all the remote helpers code
and a replace them with stubs (the patches I originally sent for
post-2.0).

It was a mistake from me to believe you would do the sensible thing for
2.0.

So to make it clear, I now request that you do:

 1) Remove all the code.

    Since my patches were removed from the list, here's an updated patch
    that applies on top of 'master'

    https://github.com/felipec/git/commits/up/remote/remove

 2) Reapply d508e4a (Merge branch 'fc/transport-helper-sync-error-fix')

    Since the code in question is no longer part of v2.0, a "possible
    regression" that you aren't even sure of cannot be the rationale to
    revert this code.

    Your commit 10e1fee (Revert "Merge branch
    'fc/transport-helper-sync-error-fix'") actively hurts the
    out-of-tree tools, so I'll consider a failure to re-revert a hostile
    action.

 3) Update the release notes to mention these tools have been removed

  Additionally, you might want to:

 4) Re-add the following release note:

    * "git push" via transport-helper interface (e.g. remote-hg) has
      been updated to allow forced ref updates in a way similar to the
      natively supported transports

    I don't know why you removed it in the first place. Clearly you pay
    no attention at all to these interfaces.

I expect you to do at the very least 1) and 2).

-- 
Felipe Contreras

Re: [PATCH] remote-helpers: point at their upstream repositories

[Felipe Contreras]

Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> > Junio C Hamano wrote:
> >> 
> >> After looking at the reverse-depends list of packages, my faith is
> >> strengthened in that the Git ecosystem is truly maturing and useful
> >> third-party plug-ins will be picked up by distro packagers.
> >
> > Where is git-imerge packaged?
> 
> I didn't see it on the archive the said Ubuntu box slurps from, but
> I did not check all the other distros.

I will help you: it's not packaged anywhere.

> > Do you want to bet? Nah, you don't *ever* want to accept you were wrong,
> > even you clearly where.
> > ...
> > This is what's going to happen: there won't be an official git-hg
> > package for *years*, if there is ever one. That is my prediction based
> > on all the available evidence, I am willing to stand by it and accept I
> > was wrong if it proves otherwise.
> >
> > Are you willing to stand by your own decisions?
> 
> If I understand correctly, you have made and you do maintain some
> packages and as an insider, you do not have to wait for "an
> outsider" to step up to make remote-{hg,bzr} packages yourself.

No, you do not understand how packaging works. ArchLinux's AUR[1] is a
community-driven repository, anybody can package anything and put it
there. That doesn't mean people can simply do `pacman -S git-remote-hg`,
far from it.

It's a placeholder for *outsiders*, not official package maintainers.

I am an outsider in ArchLinux.

> You may already have done so for your own use and told other people
> about them, and others may have chosen to wait for you to push them to
> distros instead of championing these tools by packaging them
> themselves.

You clearly haven't tried to package anything for any distro. You can't
just champion packages for a distribution. You have to go through an
arduous process before becoming an official packager.

> When you have such an influence on the outcome either way of your
> choice, I do not see much value in such a bet.

If I champion these packages I would be making you win the bet. Why
would I do that?

> But I actually think that "we package what we want to use" is a good
> thing for programs whose primary audience is the software developer
> types.  The packagers are part of their audiences [*1*].  Because of
> that, even if remote-{hg,bzr} do not get packaged for a long time, I
> doubt that it tells us what you are stipulating.  The only thing we
> can infer would be that these programs did not interest the software
> developer types to motivate them enough, and we wouldn't know why
> they found the programs uninteresting.  It may be because those who
> have history in Hg prefer to interact with remote Git repositories
> by pushing into and fetching from them using Hg tools than using Git
> tools.  It would not indicate "useful tools fall through the cracks"
> if it were the case, would it?

Or it might mean that the people that would otherwise do that packaging
instead simply copy the single file needed manually.

> Indeed I saw bzr-git that came from the Bazaar land packaged on the
> box I mentioned, and its description sounded like it is meant to
> work in such a way that allows Bazaar commits to be pushed to Git
> repositories using a bzr tool.
> 
> By the way, I also saw git-mediawiki packaged from contrib/ in our
> tree.  I found it not very credible to say "contrib/ is treated as a
> single ball of wax without much value by packagers, and we need to
> move the helpers up to core in order for them to be used more
> widely" after seeing that.

You are misconstruing what I said. I said *most* distributions treat
contrib as a ball of wax. And I said there were a few *exceptions* on
this ball of wax, like completions. remote-helpers are not part of these
exceptions (with the exception of git-bzr).

> *1* I saw you called them "wolves" at least twice recently---where
>     does such a distrust come from?

It's a jungle out there, and it's every out-of-tree tool by itself. Most
of the tools on the contrib/ area would not survive if you throw them to
those "wolves", and you know it.

[1] https://wiki.archlinux.org/index.php/Arch_User_Repository

-- 
Felipe Contreras

Re: [PATCH] remote-helpers: point at their upstream repositories

[Junio C Hamano]

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

>> Let's try this in a different way, as I sense there is a
>> misunderstanding somewhere about your "wish".
>> ...
> No, I already said I do not want the code removed from v2.0, that's why
> I sent patches that simply added a warning, and I specifically said
> those were for 2.0.

Yeah, I think there are mails crossing.  I sent that "different way"
way before I read your "already said" happened.

> So to make it clear, I now request that you do:
>
>  1) Remove all the code.
>
>     Since my patches were removed from the list, here's an updated patch
>     that applies on top of 'master'
>
>     https://github.com/felipec/git/commits/up/remote/remove

I'll do that, but just one thing to make sure---do you want the
helper to exit with status 0?

>  4) Re-add the following release note:
>
>     * "git push" via transport-helper interface (e.g. remote-hg) has
>       been updated to allow forced ref updates in a way similar to the
>       natively supported transports

I am not sure if this one is consistent with 1), as remote-hg will
no longer be with the release.

Re: [PATCH] remote-helpers: point at their upstream repositories

[Felipe Contreras]

Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> >> Let's try this in a different way, as I sense there is a
> >> misunderstanding somewhere about your "wish".
> >> ...
> > No, I already said I do not want the code removed from v2.0, that's why
> > I sent patches that simply added a warning, and I specifically said
> > those were for 2.0.
> 
> Yeah, I think there are mails crossing.  I sent that "different way"
> way before I read your "already said" happened.
> 
> > So to make it clear, I now request that you do:
> >
> >  1) Remove all the code.
> >
> >     Since my patches were removed from the list, here's an updated patch
> >     that applies on top of 'master'
> >
> >     https://github.com/felipec/git/commits/up/remote/remove
> 
> I'll do that, but just one thing to make sure---do you want the
> helper to exit with status 0?

It doesn't matter; if the remote helper doesn't respond to the commands
transport-helper exits with 128.

> >  4) Re-add the following release note:
> >
> >     * "git push" via transport-helper interface (e.g. remote-hg) has
> >       been updated to allow forced ref updates in a way similar to the
> >       natively supported transports
> 
> I am not sure if this one is consistent with 1), as remote-hg will
> no longer be with the release.

Remove '(e.g. remote-hg)', the rest still applies.

-- 
Felipe Contreras

Re: [PATCH] remote-helpers: point at their upstream repositories

[Felipe Contreras]

Johan Herland wrote:
> On Tue, May 20, 2014 at 4:55 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> > On 05/19/2014 11:31 PM, Junio C Hamano wrote:
> >> Felipe Contreras <felipe.contreras@gmail.com> writes:
> >>> Where is git-imerge packaged?
> >>
> >> I didn't see it on the archive the said Ubuntu box slurps from, but
> >> I did not check all the other distros.
> >>
> >> Michael, do you know what distro folks are doing with imerge?  For
> >> the purpose of this thread, "I do not follow distros, and I do not
> >> know" is a perfectly acceptable answer, but it would be very
> >> relevant if your answer is "I suggested these distros to include it,
> >> but so far they have been uncooperative and I haven't had much
> >> success".
> >
> > I haven't heard of any Linux distros that have git-imerge packages.  I
> > just searched the package archives for Debian, Fedora, Gentoo, and Arch
> > without finding it.
> 
> FWIW; someone has made an AUR package (a user-contributed Arch package
> recipe) for git-imerge:
> https://aur.archlinux.org/packages/git-imerge-git/

That doesn't say much. Anybody can put packages there, and it has a
single vote, which suggests not many people use it (if any).

-- 
Felipe Contreras

Re: [PATCH] remote-helpers: point at their upstream repositories

[Junio C Hamano]

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

> Junio C Hamano wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>> ...
>> > So to make it clear, I now request that you do:
>> >
>> >  1) Remove all the code.
>> ...
>> I'll do that, but just one thing to make sure---do you want the
>> helper to exit with status 0?
>
> It doesn't matter; if the remote helper doesn't respond to the commands
> transport-helper exits with 128.

You're right.

>> >  4) Re-add the following release note:
>> >
>> >     * "git push" via transport-helper interface (e.g. remote-hg) has
>> >       been updated to allow forced ref updates in a way similar to the
>> >       natively supported transports
>> 
>> I am not sure if this one is consistent with 1), as remote-hg will
>> no longer be with the release.
>
> Remove '(e.g. remote-hg)', the rest still applies.

True enough.

I was already deep in today's -rc4 tagging before this exchange, so
it may be a while until the result is pushed out, but as far as I
know the helpers are now stubs, and README no longer says "a random
version that will go stale is kept here merely for convenience".

As additional topics that touch contrib/remote-helpers/ need to be
reverted from 'next', the final pushout may take longer than usual.
We'll see.