Hi all, On Wed, Apr 3, 2013 at 12:57 AM, <d...@gnu.org> wrote: > On 2013/04/02 22:34:53, janek wrote: >> 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.
Well, i don't insist on sharing my point of view. I think we can agree to differ. >> 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. Hmm. What about doing something constructive, then? There is one big "let's do things right" patch that needs review. Despite a lot of effort spent by its author on writing a detailed description to attract reviewers, only one person cared to review it: codereview.appspot.com/7768043 best, Janek _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
