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

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: May 16, 2014, 09:23 UTC
Message-ID: <5375d903dd6c_1a1b8d33081f@nysa.notmuch>
In-Reply-To: <20140516084126.GB21468@sigill.intra.peff.net>

Jeff King wrote:

Show 18 quoted lines

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

Show 10 quoted lines

> 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