emacs-devel
[Top][All Lists]
Advanced

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

Re: PL support


From: Dmitry Gutov
Subject: Re: PL support
Date: Tue, 12 May 2020 02:03:58 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0

On 11.05.2020 18:08, Eli Zaretskii wrote:

The frequent approach in big projects is "forwarding" bug reports to
people responsible for respective piece of code.

Most of the code in Emacs doesn't have an "owner", so this cannot work
for us.  Heck, we don't even have appointed few who'd triage every
report quickly and efficiently (which would be one way of preventing
too many people from reading too many email messages).

These are the main reasons why I'm wary of adding more packages to Emacs core without solid justification.

Having more core developers should be a plus for sure, but the extra cognitive load for everyone else seems unavoidable either way.

In general, methods that work well in small projects don't scale when
you try bringing them to Emacs, both because Emacs is much larger (not
just in code size, but also in the number of widely different
expertise domains on which it is based and without understanding which
you cannot efficiently maintain the relevant parts of the code), and
because the number of people who actively track the bug list is so
small.

The methods I was referring to are used for big projects (e.g. Mozilla Firefox), as well as commercial projects of varied size with enough manpower to do the triage work.

Emacs, on the other hand, uses a "small project" workflow despite being, let's say, medium-size. And changing the workflows seems to be not in the cards right now.

So it seems to me that the logical thing would be to try to slim it down where feasible rather than simply keep growing.

Then not everybody has to be subscribed to all bug reports.

Splitting big subprojects (like Gnus) to separate mailboxes could help
as well, though.

It is not easy to track issues for a large project such as ours,
that's true.  But let's please not represent the situation as a total
catastrophe: debbugs does have keywords and sub-projects, and we have
the debbugs package that allows to use those to read only those
reports in which you are interested.  Some of us do use that package.

I suppose it would help if somebody actually used the keywords/sub-projects to forward bugs to other people.



reply via email to

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