Russell King <rmk@arm.linux.org.uk> writes:

quoted text
> On Thu, Aug 28, 2008 at 01:53:50AM +0200, Stefan Richter wrote:
>> Russell King wrote:
>> >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 text
>> (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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html