Thread (3 messages) flat view 3 messages, 3 authors, 2016-06-15

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:45:15

Russell King [off-list ref] writes:
On Thu, Aug 28, 2008 at 01:53:50AM +0200, Stefan Richter wrote:
quoted
Russell King wrote:
quoted
And no warnings before hand that the commands you were using were
deprecated.
(a) They weren't deprecated, they were moved into a different directory.
I think Junio will tell you differently on the "deprecation" bit.
The short answer is "no, not anymore".

I might have ;-), if you asked me a few days ago, and the topic of this
thread was exactly to decide the answer to that question, which was
concluded with $gmane/93793.
quoted
(b) There have been several announcements of the 1.6.0 prereleases and 
the 1.6.0 release crossposted.  Of course somebody forgot to tell you 
what you will learn from these release notes.  Unfair.
Cross posting to high traffic mailing lists doesn't guarantee that
it'll be read.  It's the wrong place to do it.

Arguably, though, the lack of information to users on the system affected
is not git maintainers fault.  It's the fault of the admins on that system
not having read the release notes themselves, and warning their users (for
whom git is a *critical* bit of software) that an upgrade is going to take
place, and they should read such-and-such.

Like a note in the system MOTD.
I've heard enough of "the changes in 1.6.0 was underadvertised and caused
users pain".  I am now aware that git has more mature and its userbase has
broadened beyond populations that read release notes (I rarely read
release notes to updates to vim or coreutils either, and that is showing
the maturity of the packages -- nothing to complain about and I am not
complaining).

But so far nobody gave "here is how I would have advertised it", until
you wrote above.  Thanks.

But that is not something _I_ could have done (and no, "I wouldn't have
accepted the change" is not an option at this point).  Are there things
that the maintainer could have done better?

I think it is fair to say that I have vetoed and am still vetoing many "UI
clean-ups" that propose to change things in a way that "should have been
this way for consistency's sake from day one, if there were no existing
user base".  During discussions to shoot down such proposals, I take
opinions from early adopters (that's you, kernel, wine and x.org people)
very seriously, perhaps to the point that outsiders would feel I am giving
them disproportionately large vetoing power.  Sadly, those "opinions from
eraly adopters" are less and less "real" but more "I'd imagine the early
adopters would say..." these days.  The process would work better if early
adopters do their part to help me by speaking up when it matters from time
to time.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help