(Sorry if you receive a dup; pobox.com seems to be constipated right now).
Jeff King <peff@xxxxxxxx> writes:
> 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 share the latter two of the above three. I was giving distro
packagers a bit more credit for their diligence in knowing what they
are packaging than you seem to be in your first point, but I admit
that it is a blind faith.
> 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.
I am fine with that.
> 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.
I do agree that a new warning every time it is run will be a more
likely to grab users' attention. The conclusion I draw from that
shared observation is that the user will be annoyed all the time,
without having a power to do anything about the annoyance, until the
report s/he (or other users) Throw at the packager, even when the
version that was packaged hasn't diverged that much yet, which does
not help end users.
I guess the ideal we want is to make sure their build break. What
if we do the README in addition to rename contrib/remote-helpers to
contrib/obsolete-remote-helpers (or s/obsolete/graduated/)? It will
give the packagers three choices and I think it hurts people much
less.
* The packagers that dump the entirety of contrib/ to somewhere
without doing anything to expose the scripts to user's PATH do
not have to do anything. The users who chose to pick them up
from there notice the missing contrib/remote-helpers, notice
"obsolete" (or "graduated"), and read README.
* The packagers that pick up from contrib/remote-helpers and
arrange the scripts to be on user's PATH will find their build
broken, because they are no longer where they expect them to be.
They will notice "obsolete"(or "graduated"), and read README.
- They can choose to pick them up from "obsolete", perhaps for
expediency, perhaps for their change aversion, but that will
not last once we grabbed their attention, and they will switch
their upstream in some later release once such a choice makes
them feel dirty enough.
- They can choose to switch their upstream right now in response
to the breakage.
I would say that the options I see are these three, and I would rank
the "warn every time" as less helpful to end-users:
- rename contrib/remote-helpers to contrib/obsolete-remote-helpers
and add README to point at the upstream.
- remove contrib/remote-helpers scripts and add README.
- warn every time the user runs the scripts.
Or am I reacting to a typo and you meant to say "I would prefer not
to instrument"? Your "shipping the warnings to end users who did
not package the software will not help" was unclear if you meant the
README that has warning or warning message they have to see every
time from the instrumented code.
--
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