Re: critical issues

[Graham Percival]

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