Apparently not posted on the issue itself, so replying to the list. "m...@mikesolomon.org" <m...@mikesolomon.org> writes:
> On 30 mars 2013, at 08:27, lilyp...@googlecode.com wrote: >> commit 6e4e69f2735a764eab2e6f70f83546461da0203b >> Author: Mike Solomon <m...@apollinemike.com> >> Date: Fri Mar 29 05:55:13 2013 +0100 >> >> Uses special X alignment for instrument names. >> >> I propose reverting it since using the instrumentName for prefatory >> material is documented and previously working behavior >> anadam.spi...@gmail.com d it is not >> clear what this will break in addition to incipits. So it is not >> really fit to be included in a stable release at this point of time. > > It is not clear what this patch does and doesn't break until people > use it. Unfortunately, the regtest checker does not pick up on > certain differences, so it is important for users testing the software > to signal these. I fix them right away. You can't fix what has not been reported, and we are talking about functionality that is used by users, based on recommendations in our code base and snippets. > You are absolutely right that it is not clear what this will break in > addition to incipits, but I'd rather deal with that as it crops up The time frame for it to crop up is not available if we are planning to make a stable release. > as it is impossible to know given our current regtest checking > suite. With Phil's pixel comparator this sort of problem will go away, > but that'd need to get integrated into the build system. > > Fixes are quick, so I just need to know the problem. I can then fix > it ASAP. You can't fix the code from users. We have had several followup issues from this patch already which makes very clear that code in our own code base relied on previous behavior. It is far too optimistic to assume that user-level code would not rely on previous behavior. Fine-tuning the balance between improvement and damage is a process taking months, based on feedback from users as well as discoveries in our own code base from developers. The fallout we have seen so far makes _very_ clear that this patch is unsuitable for inclusion in a stable release. Mixing it with several spontaneous followup issues will cause things to go uncontrollably unstable. Either this patch can be done well-confined _without_ numerous repercussions (and that does not mean rolling lots of loosely related followup fixes elsewhere into the same patch, but an actually well-confined patch with well-confined and expected changes), or it is off the plate for a timely stable release. The desire to push in patches like this was the reason I called off the stable release in the first place. It was you who said we should try for it if it is feasible. This patch obviously makes it unfeasible, and if you try wedging in a flurry of followup patches to make up for it, there will be no stable release. It was fine to try and see whether a long-standing problem can be fixed with a reasonable amount of effort and impact. But when one sees that the impact is quite larger than expected, one needs to adapt one's plans. You can't have both a stable release and patches pushed in at last minute that are shown to have a large destabilizing impact. It is not possible to have both, and I am tired of being fought as the bad guy for having to point that out time and again. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
