On 2013/04/02 22:34:53, janek wrote:
I'll risk joining the discussion.
I see valid points from both of you. I agree that it's better to fix
a broken
design than to patch it with red tape.
It isn't patched. minimum-length is used in multiple contexts/interfaces, and Mike's patch muddies the situation further.
However, if we only accepted code changes that were implementing the Ultimate Solution, i'm afraid that the development process would grind to a halt - Ultimate Solutions are obvioulsly best, but they take much much more time to implement, and usually only experts can write them.
That's the ultimate excuse to never bother about doing things right.
This should not be an excuse for broken code, but i think that we can accept patches that are iterations towards Ultimate Solution.
This one is an iteration away from a proper solution since it increases the inconsistency of minimum-length.
As i see it, Mike's patch doesn't make matters worse - it's just a piece of duct tape to make a temporary solution (i.e. current messy code) less broken.
No, it makes it _more_ broken in order to paper over an annoying consequence of the brokenness.
I think that we could add a FIXME to it and accept it, because it's not making future rewrite harder (at least it seems so to me).
How does an increase in the inconsistency of minimum-length _not_ make a future rewrite harder?
Also, we're trying to make a stable release soon, so this is not a good time to start rewriting big pieces of code.
It is not a good time shoving in behavior that is not going to survive into the next stable release (assuming that this _is_ going to be fixed in a sensible manner) either. The behavior of our stable releases should not be erratic but rather increasingly reliable. https://codereview.appspot.com/7453046/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
