From: <mj...@ga...> - 2005-04-28 07:29:53
|
Alan W. Irwin writes: > You obviously have strong views, but I think you surprised everybody by > coming in so late with them after everybody else agreed on list this was a > positive change and the discussion started by Tom had completely petered out > and the change was made by him. I know you are extremely busy so probably > the lateness of your comments was unavoidable. I emphasize that lateness > doesn't mean your views are wrong, just a surprise after everybody else > reached consensus. I'm equally surprised that you are surprised. A backwards-incompatible change of this magnitude discussed in a period of two days by 4 developers, then stuck on HEAD. You want me to be afraid of taking vacations from now on? :) > > Want to develop a different color model? Great. Do it on a branch. Have > > it be optional at first. Plan for an eventual cutover. Plan for a way > > to users to get the old behavior back. Do some research into how this > > might possibly affect people. > > You will make your points a lot better if you stay calm and also read > everything I said. This *was* the calm reply, trust me, and I did read everything you said. > Here are the last two paragraphs from my > post which you seem to have ignored. > "So I think the question really boils down to what is the best way to get > from the old default colours to the new ones without overly disrupting > users. > > For example, do you think legacy needs would be satisfied by having an > -oldcolor option that was well-advertised?" I answered this in my response -- I said what I thought needed to happen. But I'll amend & expand on that. I wrote: > > Want to develop a different color model? Great. Do it on a branch. It's easy to create & use a branch. Branches are useful when introducing potentially backwards-incompatible changes, to iron out the compatibility problems with the help of others. It's easy, too. > > Have > > it be optional at first. I.e. applications should function as before without modification. An API call or switch (at your discretion) would make the change. > > Plan for an eventual cutover. Changed my mind on this after reading Geoff's post -- the current scheme is probably fine indefinitely. So invoke a different "style" as needed. > > Plan for a way > > to users to get the old behavior back. Geoff's "style switcher" would work here. > > Do some research into how this > > might possibly affect people. Probably a good idea. -- Maurice LeBrun mj...@ga... |