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

[Dmitry Gutov <dmitry@gutov.dev>]

On 27/08/2023 14:46, Eli Zaretskii wrote:
>> 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.

Naturally. But I'm already "on board", aren't I? Just in the areas I 
know and for the number of hours that I can dedicate now.

>> 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.

What do you want me to do? Set up a standalone Bugzilla installation for 
people to try out? There is an existing demo at 
https://bugzilla-dev.allizom.org/home.

Create a migration script from the Debbugs database to Bugzilla's 
format? I could probably do that too. But that would result in nothing 
without the leadership's buy-in, just like our Gitlab instance is 
stagnating for a couple of years now.

>>> 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.

Important for allowing more people participate in the conversations.

>> 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.

I think you're failing to adjust for natural attrition.

And the effect will naturally be smaller when only one difficult part of 
the workflow is replaced, while other remain. It's just like with other 
performance optimizations.

>>> 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

I haven't had a chance to look at GNOME in detail (it has many 
components), but Firefox has 20 million lines of code as described in 
https://hacks.mozilla.org/2020/04/code-quality-tools-at-mozilla/.

And here's the top of the output from an old checkout of gecko-dev as 
some practical evidence (cloc . --not-match-f=".*_min.js" 
--exclude-dir=third_party):

   247735 text files.
   232537 unique files.
    23226 files ignored.

Language                files          blank        comment        code
----------------------------------------------------------------------------
JavaScript              72091        1147845        1682166      5270157
HTML                    89800         458806         104456      4062841
C++                     9635         704273         573546      3908919
Text                    3865          56888              0      3344737
C/C++ Header            13302         422961         797052      1987545
C                       2895         229775         288698      1461583
JSON                    1480            864              0      1003811
Python                  3491         100201         103750       425069
XML                     2673           4964           1833       332396
Rust                    841          36145          41359        273443

There are 2 million lines of Rust in the third_party dir that I skipped; 
it's hard to delineate attribution there. These are many bundled 
external repositories: some of them third-party libs indeed, but many 
are also either part of Servo (an old project of Mozilla), or utility 
libs developed for Mozilla externally. Not sure which total fraction, 
though.

>    . Emacs:
>      - started in 1986
>      - 3 million lines of C and Lisp
>      - release schedule: roughly every 9 months

And for Emacs:

     5332 text files.
     3720 unique files.
     3768 files ignored.

Lisp                  2281         199969         245681        1637882
C                     367          87344         102056          412372
Text                  56           9680              0           323232
C/C++ Header          292          15336          25859           76814
Bourne Shell          37          13036           6386            58332
TNSDL                 1              0              0             42864
m4                    147           2054           1261           22642
Objective-C           10           4291           2832            18917
TeX                   28           4021           6237            18263
make                  49           2463           2827             8731
C++                   23           1865            858             7700
Java                  41           2769           2568             7622

(If we substract cedet, org and gnus, for Lisp the number of code lines 
will be 1372496).

Perhaps Lisp is denser than JavaScript or C, and et cetera, but it's 
hard to argue that Emacs is more complex, or even comparable, to 
Firefox. And if they reached this size in 20 years rather than 40, it's 
an evidence to better productivity rather than the opposite, right?

> 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.

According to 
https://blog.mozilla.org/en/products/firefox/the-new-firefox-by-the-numbers/ 
(article from 2017),

   > 700 authors contributed code to Firefox over ~1 year

   80 of them were volunteers, "contributors from all over the world".

and by those 700 authors:

   75,342 files changed
   4,888,199 lines were added
   6,886,199 lines were changed

The more recent article (link earlier in this email) says that they're 
using Phabricator for code reviews and an in-house CI system. I can't 
comment on either of these systems.

There is a whole lot of organization around this project, but since 
we're actually much smaller, I don't know how much of it will be 
relevant enough to get into researching.