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.
> - 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
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
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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html