emacs-devel
[Top][All Lists]
Advanced

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

Re: Omitting Windows-specific parts from infrastructure changes


From: David Kastrup
Subject: Re: Omitting Windows-specific parts from infrastructure changes
Date: Wed, 21 Jan 2015 21:49:29 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> Date: Wed, 21 Jan 2015 11:39:34 -0800
>> From: Paul Eggert <address@hidden>
>
>> This is starting to get ridiculous.  Let's drop the discussion, as we're 
>> not making any progress (quite the reverse, I'm afraid).
>
> I already suggested several ways to resolve this.  Feel free to make
> your own suggestions, provided that the result will be that such
> changes are done everywhere, without unduly punishing your fellow
> developers who offer you help to do parts of your job.

It's not his job.  We are rather talking about how to enable different
people interested in different things to continue working on code in the
same Emacs repository.  As far as I know, it is nobody's _job_ to do so
currently (Gerd Möllmann once had a job working on the Emacs 21 display
engine if I remember correctly).  Neither the parts he did are his
"job", nor the parts he did not do.

In a project driven by volunteers it makes good sense when people invest
those kinds of work that otherwise would cause a much larger workload.
Sometimes this does not work, like when basically the best-suited person
for pretty much any task is the same person.  In that case, there is
some sense in others doing part of the work in spite of them being less
efficient at it, simply because there are limits to what a single person
can do.

However, in a project as large and diverse as Emacs, when we indeed have
the situation "if I had to tell anybody what I am doing, I would not
have enough time to do it", this is basically an unmaintainable
situation where indeed it might be more prudent from refraining to a
change where not even the resources for properly implementing it
throughout the code base _or_ communicating the necessary changes are
available.

-- 
David Kastrup



reply via email to

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