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.
On Thu, Aug 28, 2008 at 01:10:14PM -0700, Junio C Hamano wrote:
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.
I think it's fairly clear by now that we aren't shy about sharing our
opinions ... if we're asked for them. So do we need a git-oldtimers
mailing list where you can post proposals so we can NACK them?
--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
On Thu, Aug 28, 2008 at 01:10:14PM -0700, Junio C Hamano wrote:
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.
I think just freezing the UI is not a good answer. Git's UI evolved too
wildly and uncontrollably in the early days and I think in the long run,
tweaking out at least some of the inconsistencies is good idea, IMHO.
Not that I would think there should be any more *major* changes
upcoming, I mean mostly small stuff (all that I hate the
git-checkout/git-reset dichotomy or git-add/git-rm asymetry, touching
this would be just too radical change by now, IMHO).
The only problem I can see with the transition were the deprecation
messages, as was mentioned much earlier in the thread. If it's going
away in few years, Git should start to nag about it now. Then, all whom
it concerns _will_ realize this and slowly transition at their own pace.
Also, maybe we should require all internal references and documentation
updated when *declaring the feature deprecated* (not when removing it),
even if it means delaying the phase-out; that was the other major
complaint in this thread that is worth remembering, I believe.
--
Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC. -- Bill Gates