Re: critical issues

[Trevor Daniels]

Graham Percival wrote Friday, December 31, 2010 11:20 PM


> 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?

Well, I don't intend to die in the ditch over this,
but the concern I had was this.  Quite a lot of the
documentation was written, not by inspecting the code
to see what was intended, but by experimenting and
writing up what was found.  I certainly worked that
way, and I think Mark and Keith did recently in
documenting the new spacing stuff.  In doing that we
had no idea whether the things we find are intentional
or a happy coincidence of bugs.  Now if you can work
in something about "working as intended or documented"
wrt determining critical bugs I'd be happier.

> > Also, without the filter of intentionality, you end up arguing 
> > about whether the
> > feature is important, which is much more subjective.
>
> Yes.

It is, but it might be relevant if fixing a minor
bug exposed a more serious one.

Trevor