On Thu, Dec 30, 2010 at 08:43:36PM +0000, Keith OHara wrote: > Trevor Daniels <t.daniels <at> treda.co.uk> writes: > > Graham Percival wrote Thursday, December 30, 2010 3:56 AM > > > > > > I want to keep the word "intentionally", though -- if something > > > only happened to work because of a happy coincidence of bugs, then > > > "breaking" that should not be a Critical bug. > > > > I'm not sure about this. The purpose of selecting > > out bugs to be critical is to ensure the user who > > keeps up to date with the stable series of releases > > can be sure nothing in the new release is going to > > break his scores. He doesn't care whether something > > worked just by a happy coincidence of bugs. [...]
Suppose we have a pair of memory leaks. One leak writes junk to memory as part of the guile initalization, and another leak reads junk from memory as part of the spacing algorithm. This pair of bugs happens to result in a pair of objects not colliding. When we fix one of these bugs, the objects happen to collide. Oh no, it's a regression! However, lilypond never intentionally tried to avoid those objects colliding -- in fact, intentionally avoiding this collision would require a fair chunk of extra code. Should we hold back a stable release just for this? This isn't a theoretical example. I can't remember if the cause was a pair of memory leaks, but we *have* introduced collision "bugs" due to general spacing improvements, where the lack of collisions was never intentional. > Also, without the filter of intentionality, you end up arguing about whether > the > feature is important, which is much more subjective. Yes. I'm not saying that the new behaviour wouldn't be a bug; just that this bug should not delay a new stable release. Cheers, - Graham _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
