Felipe Contreras [off-list ref] writes:
Junio C Hamano wrote:
quoted
- 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.
quoted
- "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.
quoted
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.
Junio C Hamano wrote:
Felipe Contreras [off-list ref] writes:
quoted
Junio C Hamano wrote:
quoted
- 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.
quoted
quoted
- "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.
quoted
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.
quoted
quoted
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