Re: emacs IDE features

[John Wiegley <johnw@newartisans.com>]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

>> - Core libraries

> You mean "each core library", I presume. IMO, it is impractical to have one
> lead and one team for all, or even most of them.

Right, I did mean that.

>> - External resources

> Not sure what that means.

Someone who is willing to keep an eye on things like reddit.com/r/emacs,
emacswiki.org, and other external resources, that really have nothing to do
with emacs-devel at all.

This would largely be a non-technical role: more a "community liaison" type of
thing. Are the informational and educational needs of the community being mit?

If I could pick anyone for this, it would be Sacha Chua. She has already been
serving in this capacity more or less, so I'd like to invite her to "report"
on the State of The Emacs Community with a touch more formality.

>> - Each supported platform

> This needs more detailed description. What is a "platform"? We have Posix
> systems with and without GTK/Lucid/Motif, with and without Cairo. Are those
> the same platform, or do we need experts for each toolkit? Are all Posix
> systems the same "platforms", or do we need separate experts on GNU/Linux,
> *BSD, Solaris, and Irix?

I suppose these dividing lines need to be drawn "as needed" and based on
available volunteers. If a group of platforms can be served by one person
(say, the *BSD family), great; if it becomes too big a job, or we've divided
it wrong, we make a change.

>> - Performance

> I don't think this should be a separate team. Each core team should be
> responsible for performance in their area, because solution of any
> performance problems in each area is specific to that area.

I agree, but I also don't agree.

I'd like to nominate a "performance czar", whose job is to construct and
maintain a performance benchmarking suite, run on all platforms as part of the
build, and whose output would be tracked over time to detect degradations and
inform us of the impact of changes.

In the Haskell world, we have exactly this for the GHC compiler:

    https://mail.haskell.org/pipermail/ghc-devs/2015-May/009032.html

The dashboard linked to in that message measures the performance impact of
every commit automatically, presents graphs, etc. The software behind it is
freely available, and its author is keen to receive usability suggestions.

I know that some don't believe performance is an issue in Emacs, but I would
counter with: maybe not the way *you* use it, or the environment you use it
in. There are performance issues in nextstep Emacs on OS X, for example, that
make it unusable for me. A benchmarking suite would help pinpoint why, and
ensure that once fixed, it wouldn't break again.

There's no harm in knowledge. If someone out there is interested, it really
could help improve our project. Plus, it doesn't require knowledge of either C
or Emacs Lisp. This could be a good starter project for someone who wants to
get involved, but doesn't feel confident submitting code or documentation just
yet.

John