Russell King <rmk@xxxxxxxxxxxxxxxx> writes: > 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. >> (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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
