bug policy (was Re: Release process)

[Stephen Leake <stephen_leake@stephe-leake.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> > These considerations will become valid only when we have enough
>> > developers paying attention to bugs that are reported.  (That includes
>> > you, Stephen, btw.)  
>
> (Upon re-reading, I apologize for being so blunt.  It just feels too
> lonely there, at times.)

I didn't see it as offensive; just a gentle reminder.

I relate the lonely; I'm inordinately pleased when someone actually
posts to the ada-mode mailing list, even if it's just to report a bug
:).

>> During the last feature freeze, there were reminders on this list of the
>> bugs that were deemed release-critical.
>
> That's the last resort.  There are gobs of bugs that don't block
> anything, and some of them are left alone for far too long.

For your definition of "too long". As far as the Emacs project is
concerned, only release-critical bugs have been left "too long".

I don't see how it can be any other way, in a volunteer-staffed free
software project; no one is paid to fix bugs.

Another motivation for working on Emacs in general is the desire to work
on a project that has a useful product. But the connection between
fixing bugs and producing a useful Emacs is very tenuous in general; it
is very direct for some bugs (the ones that occur in common or important
use cases), but not for others (obsure bugs that are hard to reproduce).
Clearly lots of people find Emacs useful despite the outstanding bugs.

The bugs in common or important use cases tend to get fixed, because the
package authors are still around to care about them.

But we might learn something from triaging the existing bugs; I'll put
that on my list of things to think about while I'm  procrastinating
everything else on the list :).

> Even a prompt response that just says the bug was reproduced (or not),
> and ideally also with results of some initial investigation and/or
> request from the OP to provide more details or try something -- even
> this would be progress.

That is the level of support I provide for ada-mode. But that started in
the context of getting paid to use Ada, so it was easy to interpret that
as getting paid to maintain ada-mode. Now that I'm retired, I find
myself much less motivated to maintain ada-mode.

The lack of such support for Emacs in general is one reason I learned to
be proficient in elisp, so I could fix any bugs that I encountered in my
Emacs use. That's not an option for every user, but it is what I
recommend to any team that wants to use Emacs; make sure there is
reasonable access to an Emacs guru for this kind of support. 

> And then there are small patches submitted there -- review and comment
> will be appreciated.  Patches that are no-brainers, e.g., fixing a
> typo or some other obvious mistake, should be pushed if there are no
> comments after a week, say.

I understand the process; the issue is the motivation. Clearly, it is
far more fun to work on the next Cool Feature, than to chase bugs in
yesterday's Boring Feature :).

>> There may be other release-critical bugs that I can usefully work on.
>
> The problem IMO is not the release-critical bugs, it's all the rest.

Exactly why are those a problem?

Clearly each bug was some sort of problem to at least one user at one
time, but why is it an important problem for the Emacs project in
general?

Do potential users get turned off by the number of bugs?

We don't lose funding by ignoring bugs; what do we lose?

-- 
-- Stephe