[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New Package for NonGNU-ELPA: clojure-ts-mode
From: |
Dmitry Gutov |
Subject: |
Re: New Package for NonGNU-ELPA: clojure-ts-mode |
Date: |
Sun, 27 Aug 2023 15:59:23 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 |
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.
- Re: New Package for NonGNU-ELPA: clojure-ts-mode, (continued)
- Re: New Package for NonGNU-ELPA: clojure-ts-mode, Eli Zaretskii, 2023/08/27
- Re: New Package for NonGNU-ELPA: clojure-ts-mode, Stefan Kangas, 2023/08/27
- Re: New Package for NonGNU-ELPA: clojure-ts-mode, Eli Zaretskii, 2023/08/27
- Emacs release cadence, Dmitry Gutov, 2023/08/27
- Re: Emacs release cadence, Eli Zaretskii, 2023/08/28
- Re: Emacs release cadence, Dmitry Gutov, 2023/08/28
- Re: New Package for NonGNU-ELPA: clojure-ts-mode, Po Lu, 2023/08/27
- Re: New Package for NonGNU-ELPA: clojure-ts-mode, Dmitry Gutov, 2023/08/27
- Re: New Package for NonGNU-ELPA: clojure-ts-mode,
Dmitry Gutov <=
- Re: New Package for NonGNU-ELPA: clojure-ts-mode, Eli Zaretskii, 2023/08/27
- Re: New Package for NonGNU-ELPA: clojure-ts-mode, Dmitry Gutov, 2023/08/27
- Re: New Package for NonGNU-ELPA: clojure-ts-mode, Eli Zaretskii, 2023/08/27
- Choice of bug tracker, Dmitry Gutov, 2023/08/27
- Re: Choice of bug tracker, Eli Zaretskii, 2023/08/28
- Re: Choice of bug tracker, Stefan Kangas, 2023/08/28
- Re: Choice of bug tracker, Dmitry Gutov, 2023/08/28
- Re: Choice of bug tracker, Eli Zaretskii, 2023/08/29
- Re: Choice of bug tracker, Philip Kaludercic, 2023/08/29
- Re: Choice of bug tracker, Po Lu, 2023/08/29