[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug policy (was Re: Release process)

From: Eli Zaretskii
Subject: Re: bug policy (was Re: Release process)
Date: Thu, 12 Nov 2015 18:12:25 +0200

> From: Stephen Leake <address@hidden>
> Cc: address@hidden,  address@hidden
> Date: Wed, 11 Nov 2015 17:06:20 -0600
> >> 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 think I agree.  A bug can be non-critical, in the sense that
we could live with it as we did until now, but still it prevents or
interferes with someone's use case.

Or maybe we should classify more bugs as release-critical ;-)

Speaking about which: what exactly is your definition of criticality?
The one we employ now is pretty conservative; for example, a bug that
existed in previous releases is not considered release-critical.  So,
for instance, bug#18997 won't be considered critical, although it
involves an abort, something that would be triaged as "critical" in
any software maintenance out there.

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

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

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

Many bugs in the database are neither obscure nor hard to reproduce.
Those are the ones I'm talking about.

We could also use more aggressive triage, and clearly mark
non-reproducible and obscure bugs as such.  Instead, we let them hang
in limbo, which probably gives a wrong impression to someone who takes
an impartial look at our open bugs.

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

I think most of our packages don't have such authors around any more.

As for the "important" part, it's many times in the eyes of the
beholder.  A bug in a feature or package you never use will not appear
important to you, and it's not easy to understand its importance even
when the OP explains that.  On balance, I find this kind of approach
not useful; a much more useful approach IME is: "do I understand the
issue, and can I fix it"?

> 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 :).

Thanks, that will be useful.  It's also possible we should use
"wontfix" and "unreproducible" tags more aggressively.

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

Alas, most of Emacs is in this orphaned state.  If veteran
contributors don't step forward to help more with even the initial
analysis of the reported bugs, the job of those few who are involved
in bug fixing becomes much harder, and the result will be more bugs
left unsolved.  If the bug is specific to a platform to which I have
no easy access, or involves some software which I cannot or don't want
to install, I can only marginally help, mostly by asking questions and
suggesting ideas.  If someone who does have access to a similar system
reproduces the bug and provides its analysis, it is frequently much
easier to propose a solution and even come up with a possible patch.
Few users can help with such analysis, but most active contributors
here have enough knowledge to do so.

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

I think we have here enough of such gurus, so I'm lobbying for them to
become more involved in handling bugs reported to the tracker.  The
main motivation, IMO, is twofold: (1) solving bugs helps your fellow
users, and (2) working on a bug almost always provides an ample
opportunity to learn something new about Emacs.

> > 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 :).

Emacs features are usually anything but boring.  Most of the code was
written by first-class experts in design and implementation (myself
excluded), so reading and understanding it is a great investment, IMO.

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

A project that lags on fixing bugs doesn't have a bright future, IMO,
for several reasons.

For starters, users don't like that for obvious reasons, so such a
project most probably loses users it could have retained.

A more subtle reason is that working on bugs tends to proliferate
knowledge about the project's design and internals, so not working on
bugs runs a very real risk of slowly losing that knowledge and
increasing the number of areas where no one can make non-trivial
changes.  We are almost there already: notice the bugs with font
handling and with complex script layout.  I'm afraid the X display
back end, the GTK toolkit, and the Cairo-related code will follow, now
that Jan stepped down.  These are not obscure unimportant parts of
Emacs, far from that.  We need to grow experts in those areas soon
enough, or we will start accumulating grave bugs that no one can
solve.  How else do you gain such experts if not by encouraging
motivated contributors to start working on bugs in these areas?  The
only other way of gaining experts is to wait for them to magically
materialize, but that doesn't work very well IME.

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

We lose our future, I'd say.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]