emacs-devel
[Top][All Lists]
Advanced

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

Re: New Package for NonGNU-ELPA: clojure-ts-mode


From: Eli Zaretskii
Subject: Re: New Package for NonGNU-ELPA: clojure-ts-mode
Date: Sun, 27 Aug 2023 14:46:19 +0300

> Date: Sun, 27 Aug 2023 14:07:29 +0300
> Cc: philipk@posteo.net, danny@dfreeman.email, stefankangas@gmail.com,
>  emacs-devel@gnu.org, manuel.uberti@inventati.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> > But the important part is what was said many times in this and other
> > similar discussions: those who want these deep changes are invited to
> > step up and become Emacs (co)-maintainers, and then make the changes
> > and actually use them for Emacs development, instead of telling others
> > how to do their jobs.
> 
> If the cost is taking over entirely and dedicating 7+ hours every day to 
> Emacs (as you said you do), this is obviously a prohibitive barrier.

The real costs will not be known until you actually do it.  I hope
it's not more, but it could well be less, especially if enough people
come on board.

> I don't think it's a reasonable ask when I'm just talking about
> using a real bug tracker, for example.

It is definitely _un_reasonable to suggest/demand such changes when
you are doing nothing in practice towards that goal.

> > It is at least unfair to expect us to do our
> > job well, and then tell us how to do it and what tools to use for it.
> > And that is even before we recall that those alternative tools are
> > either semi-broken or lack important features (or both) that the
> > existing "obsolete" tools offer us basically for zero cost.
> 
> The existing tools "lack important features" to such a degree that it's 
> not even funny.

"Important" for whom?  We are doing a reasonable job with them, given
the available human resources, don't we?  Bugs are triaged,
investigated, and most of them fixed; patches are reviewed, commented,
and installed.  We'd love better tools -- who won't? -- but every tool
we examined until now had important gaps.

> And the cost is not zero, the cost is the people that never set foot
> in our community.

That cost is largely imaginary, and "never set foot" is an
exaggeration.  The same was said about the switch to Git, for example,
but the situation hasn't changed much, if the number of active
maintainers/developers is concerned.  It is better, but only slightly
so.

> > And none of the alternatives withstood the test of time and/or the
> > magnitude of the project.
> 
> Should we mention other big projects? GNOME? Firefox? Emacs is complex 
> but not that unique.

If someone has intimate knowledge about those, then yes, I'd be
interested to hear an objective comparison.  Until then, here are the
facts I could gather:

  . GNOME:
    - started in 1997
    - 2 million lines of C
    - release schedule: every 6 months
  . Firefox
    - started in 2002
    - 2.4 million lines of C, C++, and Javascript
    - release schedule: every 4 weeks
  . Emacs:
    - started in 1986
    - 3 million lines of C and Lisp
    - release schedule: roughly every 9 months

What is missing is the number of active developers in each project
(which requires a definition of "active developer"), the means and
tools they use for issue tracking, and whatever else is relevant.

So yes, Emacs _is_ larger and older.



reply via email to

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