On 2013/08/30 08:55:15, mike7 wrote:
On 30 août 2013, at 10:11, mailto:d...@gnu.org wrote:
> On 2013/08/30 07:41:49, mike7 wrote: > >> I'd still argue that (2) is the best way to go as it is a > one-stop-shopping way >> to clear all these bugs (and perhaps more) as they arise. > > Since we are currently in the process of recovering from the last > one-stop-shopping way to clear bugs galore which is where all those > regressions are actually from,
The skyline code was not written to address bugs.
Neither is this here. We are talking about changing established behavior to something different. And the motivation for that _is_ the responsibility of the skyline code. But if you want a "one-stop-shopping way to clear bugs galore" from which we are still recovering, take a look at issue 3199. It's responsible for at least issues 3359, 3360, 3385 and was pushed without even waiting for the review to clear.
LilyPond's previous spacing algorithms weren't buggy - they were just less snug than they are now.
"Snug" reminds me of issue 2527, another problem solver responsible for issues 3363, 3465, 3497.
> I suggest that we refrain from embracing your somewhat optimistic > estimates until after wrapping up a stable release.
I don't see the relationship between the two.
Which makes it a good thing that you are not pursuing a career as project manager. At any rate, we are trying to stabilize our code base in a timely manner suitably for a stable release, and the established track record of ingenious solutions solving all problems in one fell swoop does not suggest that this is the way to go. https://codereview.appspot.com/9295044/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
