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

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: May 19, 2014, 01:31 UTC
Message-ID: <53795ef8e4023_10da88d30825@nysa.notmuch>
In-Reply-To: <xmqq1tvq4r43.fsf@gitster.dls.corp.google.com>

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.

Show 19 quoted lines

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

Show 5 quoted lines

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

Show 5 quoted lines

>   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