Re: PL support

[Dmitry Gutov <dgutov@yandex.ru>]

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.