Re: New maintainer

[John Wiegley]

>>>>> Eli Zaretskii <address@hidden> writes:

> The issue is merely how to organize the maintainership, and how to define
> the division of responsibilities with c-maintainers, if there will be such.

This is a great question, and one I've been pondering myself, since the most
pressing variable for me in all of this is time.

Where I think I can contribute best is the bigger picture, or "meta issues":
weighing in on technical discussions, making higher-level decisions about
technical direction, keeping an eye on user experience within the community
and the quality of Emacs resources, coordinating volunteers, ensuring proper
legal forms are maintained, liaising with the FSF, and assisting other
maintainers so they don't burnout and receive the help they need.

What I probably don't have enough time for is giving all the issues, code
submissions, and discussions on emacs-devel, the depth and refinement they
deserve. This is where I've noticed Eli (and certainly Stefan) doing an
excellent job. I'm quite impressed by their energy and involvement. I would
need such people to make this job even possible within the constraints of my
life.

I also think that detail-level maintenance is far more likely to induce
burnout, since the flood at that level can be intense. Seeing the number of
replies by Eli and Stefan in the past few weeks has been impressive to say the
least, and requires a special kind of interest and energy to maintain. How do
we best support them? How do we find more hands to make lighter work for our
stalwart contributors?

Meanwhile, I want to think about the road leading to Emacs 26, and to work
with Eli, and the community as a whole, on what makes the most sense in terms
of what we have now, and what we want Emacs to become. For example, we have
compute-intensive applications -- such as Gnus -- that cannot take advantage
of the additional power offered by multi-core CPUs. How do we add concurrency
without increasing our maintenance burden due to impossible-to-reproduce bugs,
race conditions, and terrible error messages (a Backtrace, but from which
thread?). It will require significant collaboration to decide exactly what we
want, and what Emacs needs, from such features.

Another area we're falling behind in is the type of IDE features that are
taken for granted in special-purpose editing environments, such as effortless
code browsing, refactoring, and more interactive debugging. The things you can
do when editing Java and Javascript are downright impressive, and I see no
reason Emacs can't compete better here.

It would be hard to care about these issues in sufficient depth if the job of
project maintenance also required keeping an eye on every issue and technical
discussion. I think having co-maintainers (maybe several) who are good at
detail is absolutely essential to getting this job done.

John