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