Re: bug policy (was Re: Release process)

[John Wiegley <jwiegley@gmail.com>]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

> Speaking about which: what exactly is your definition of criticality?

We may always need to be somewhere flexible here: Whatever the pride of the
developers would not allow to be delivered.

If I say "crash bugs", it wouldn't mean all crash bugs, since some are very
niche. If I say "crash bugs on GNU systems", we might let a terrible bug slip
through on Mac that could have been solved easily.

I have a feeling that most engineers, looking at a bug, will have a sense of
whether it will be embarrassing to ship with that problem. These should all be
promoted to release critical, and demoted only if several other people agree
that it shouldn't hold up the release.

> We cannot force volunteers do anything, but we can try persuading them. If
> we don't, then what do we need project leadership for?

The fact is, Emacs *could* slip into a permanent maintenance state, where we
never add a single new feature, and work only on bugs very slowly. I could
well imagine myself using 24.5 for the next 20 years just fine.

But there are annoyances for some that deserve feature work to resolve, and
this is what pushes Emacs forward. That, and great ideas that are just too
good not to implement.

It's hard to motivate people when the status quo is actually pretty darn good.
We'll have to think creatively about this, since I really would like our bug
database to reach zero at some point.

> We need to grow experts in those areas soon enough, or we will start
> accumulating grave bugs that no one can solve.

I think you've just made it hard for me to fall asleep tonight.

John