Hey, that took only a month, which means that it’s time, once again, to display some Emacs charts.
And since this is the tenth post in this series, I thought I’d natter on even more than usual. And perhaps some more about… having some vague goals as being the Emacs co-maintainer? OK, let’s see how this post goes.
So: This is the tenth time I’ve posted about closing 10% of the open Emacs bugs, which begs the question… Isn’t ten times ten percent, like… 100%? But there’s still bugs in the bug tracker!? THIS IS ALL A SWINDLE.
But for each stretch, I’m doing 10% of the remaining bugs in the bug tracker, so best case scenario would have been… er… maths is hard; let’s iterate:
(cl-loop with sum = 0
and total = 100
for i from 1 upto 10
do (cl-incf sum (* total 0.1))
(setq total (* total 0.9))
finally (return (list sum total)))
=> (65.13215599000002 34.86784401000001)
Closing 65% of the bugs would have been the absolute max with this methodology, and no matter how many iterations I’m doing, I’m not getting to zero. It’s like that paradox.
Instead we’re down about 45%, from about 4400 bugs to 2690 bugs.
Looking at the charts a bit:
I think you can pretty much pinpoint the date I didn’t have to work any more after the startup I was a co-owner of was bought and found myself with a lot of free time on my hands? Kinda? So I’ve been basically working full time on Emacs bug fixing (and triage) for a couple years (with some holidays at random) instead.
This last 10% stretch started July 13th at 2820 open bugs, and we’re down to 2690 today.
And 50% of issues are closed within a week, which isn’t too bad.
The rate of bugs reported seems to be roughly linear over the years.
I love programming myself, and applying patches from other people is… er… not as viscerally pleasant as writing code? But applying patches scales a lot better, so I’m trying to have a quick turnover on patch submissions (having a Forge-like thing with pull requests would be nice *cough* *cough*), but let’s look at the stats for bugs that are tagged with “patch”.
Yeah, there’s usually a lot of bug reports that have patches that are works in progress, and then nobody actually applies them. So I’ve been making it my business to whittle down this category of bug reports: Either by getting it applied, or ruling out applying them. (The vast majority is in the former camp.)
Let’s look at the last year:
We seem to be getting down to 60, but then bouncing back up… It’s not like this is static: New patches are submitted all the time and applied, but the backlog seems to be constant(ish). Since I’m a veteran stock broker, let’s do some technical analysis:
So I imported the image into LibreOffice, then took a screenshot, and then printed that out, and then took a picture of the print-out. (This is industry best practices.)
We’re really seeing lot of support for the 60 level, and as an analyst, I’d say that it’s impossible to break through that level.
WE DID IT! WE BROKE THE RESISTANCE! WE”RE DOWN TO 51!!!!
To zoom out a bit: How are we doing in the activity dept?
This is the number of commits per month (mangled to remove merges and other artefacts, and then smoothed a bit). We’re currently at about 400 per month, which, if my knowledge of the philosophy of mathematics is correct, is a bit more than ten per day.
In itself, it doesn’t really say that much: I mean, I myself could just be committing a lot of junk and then fixing it, and that’d make the graph go up.
Emacs switched to git (from bzr) in 2014 to get… more contributors. But… It didn’t really seems that that had much of an effect — perhaps we just lost a lot of people who really hate git?
Of course, Emacs still has a fleet of people responsible for various sub-systems, and they’re working away efficiently on those, and co-maintainer Eli Zaretskii is handling all the difficult internal Emacs things that I don’t quite know how actually work, even after all these years…
But what I really, really want to see happening is that we get an increase in the number of “drive by” contributions: That is, contributions from people who aren’t living on the emacs-devel mailing list, but just see some problem, fix it, and then submit a patch or two.
Because that’s what I think makes for a healthy development environment: I’ve been using Emacs since the late 80s — yes, I’m really old — and we need young people to come in and do new stuff. This is totally happening in the wider Emacs culture (creating packages for GNU ELPA/Melpa, for instance), but I definitely feel like there’s a perceived barrier to submitting stuff to Emacs itself.
So I want to, ideally, have a super-quick turn-around on patches from “out there”: Either feedback on why it’s not the quite right thing, or getting it into Emacs toot sweet.
Is my nefarious strategy working? I’ve got the data, so let’s p-hack the shit out of it until it makes me look good. I mean… apply… sound statistical analysis to the data. Yeah. That’s the ticket.
This is the number of commits, per month, from people who do less than five commits per months.
Look at that chart! By just extrapolating that line a few years, it’s clear that by the year 2049, we’ll have nine million contributions from drive-bys per month! Whoho!
(I’m sure that’s correct.)
And this is people contributing one patch per month.
I think we’re on the right track here? At least it seems hopeful.
Zooming way out to the entire history of Emacs, it would seem that we kinda have as many contributors as ever before, but this chart is grossly misleading: In the olden days, many things were developed externally, and then applied in one single commit, under a single name, which makes it look like there weren’t many contributors in the 90s, for instance.
And here’s the same with commits instead of contributors, which shows that the rate of development is, indeed, slower than it was in the 90s. (And again, this chart is also misleading because of the jumbo-application strategy of many of the major sub-systems in the 90s.)
But it’s certainly not looking bad or gloomy or anything: Emacs is mature and stable, but we’re still getting a lot of stuff done, and new functionality is added to the Emacs core all the time. (The thriving Emacs package system is totally separate from this, of course.) I think that about a decade ago, people were feeling that Emacs was a bit stagnant, but that’s not the feeling I’m getting now.
The Emacs 28 release branch will be cut (according to plan) in mid-September, and we’ll get the release out some months after that. The major new bits will be the native-compilation, pure GTK stuff, and all of the in-tree Emacs code now uses lexical binding. (But I guess the tree-sitter/LSP stuff will be more of an Emacs 29 thing.)
But there’s a whole bunch of other stuff in Emacs 28.
And there could be more!
(Just a reminder: Working on the development version of Emacs is easy on most operating systems. It’s trivial on Debian, Ubuntu and Redhat, of course, but it’s also easy on Windows, MacOS (and with Brew), OpenBSD, FreeBSD and even NetBSD.)
Patches welcome.
Hi. I’m a drive-by contributor, and have a number of commits in emacs itself, and I DREAD actually committing anything into the main tree. The reason: we have a number of inscrutable rules about commits that go way beyond keeping the code tidy, and go well into OCD territory. The two-spaces-after-period thing in comments. The requirements about stating the functions and variables and files that were affected in the commit log. And so on. I feel like every time I would send a patch, I get a laundry list of cargo-culty things to “fix”. No idea if this has an observable effect on contributions, but it certainly isn’t helping. I don’t have time to fight this battle on emacs-devel right now, but it’s one person’s opinion.
I agree completely with all your points. I don’t necessarily think that Emacs has more rules than other large projects (for instance, some projects refuse out-of-hand all patches that don’t have a case to reproduce, as well a test suite for the fix), but the formalisms that Emacs does have (the ChangeLog-style commits and other peculiarities) are very unusual indeed. For what it’s worth, I never insist on any of the things you’ve mentioned when applying patches (but I instead just fix that stuff up myself and then tell the committer what I’ve done).
(I mean, I see the point in er educating the submitter about the format we expect the patches to follow, but I think that can wait until the tenth submission.)
Lars, thanks for your thankless work. You’re helping to ensure Emacs’s future.
FWIW, about the “rules”:
1. I *really* appreciate the two-spaces rule, because without it, M-f and M-b don’t navigate by sentence–they aren’t useful anymore. It’s always frustrating when editing text that has a mix, and those commands suddenly skip multiple sentences. It also makes prose in monospaced fonts easier to read, by making it easier to visually scan by sentence. I’ll never understand the resistance to this concept, especially in the context of plain-text and source code.
2. The changelog format can be tedious, but I think it’s worth it, because it makes it easy to search commit history to find what commits changed what symbols. Without it, a diff in the middle of a definition might not have the context lines to make it show up in a git diff search. It also makes it easier to grok what a commit does at a glance, without having to scan through a long diff to see what definitions are changed. And in a big, old-and-yet-young project like Emacs, those are frequent operations. And besides, formatting those changelog entries is mostly handled by Emacs itself, now. With Magit, I just press “C” in the diff buffer while editing the commit message in another window, and it does the hard work for me. (So it’s kind of like when people complain about Lisp being hard to edit–if it is, it means your editor isn’t doing enough for you.)
Well, my two cents. Please keep up the good work.
FWIW I have numerous items in my init.el with comments like “I should upstream this”, and the main reason I don’t is because I don’t have assignment from my employer. I’d be fine assigning my own rights to the FSF, but getting $BIGCORP to sign some legal document—and repeating it every time I get a new job—has proven to be a bar too high.
Thank you for all your hard work, Lars!
Hi Adam,
> the two-spaces rule, because without it, M-f and M-b don’t navigate by sentence–they aren’t useful anymore.
I’ve got a lot of one-spaced text nicely navigated through with M-e / M-a after setting sentence-end-double-space to nil.
> I’ll never understand the resistance to this concept, especially in the context of plain-text and source code.
As a non-native English speaker, I had *zero* knowledge about “two-space rule” before getting to Emacs.
Studying this topic, I’ve got to this article just recently: https://practicaltypography.com/are-two-spaces-better-than-one.html .
Supposedly, others might find it an interesting read too.
(The research mentioned in the article is available freely currently.)
Thank you for these – as always – fascinating statistics, Lars!
> This is totally happening in the wider Emacs culture (creating packages for GNU ELPA/Melpa, for instance), but I definitely feel like there’s a perceived barrier to submitting stuff to Emacs itself.
Yeah..
My own experience (the first steps in Emacs made over a year ago) confirms this.
I’ve been contributing little by little to Company package (via GitHub) during the last couple of months.
And for quite the same period of time I’ve been tracking the development of Emacs (diffs and mailing lists).
Having a list of the things I’d like to write/send patches for (including documentation fixes), I still couldn’t get to a point feeling ready to do so.
Even submitting a bug report or writing to a mailing list *feels* being an extremely tedious task with a highly potential outcome of feeling stupid/uncomfortable (because of certainly making mistakes), and/or out of place (because of certainly not being in the context).
Tedious because I’ve got to study too many things simultaneously:
– Emacs intricacies.
– Mailing lists handling (of course I want it done only with Emacs, so see #1).
– Elisp intricacies.
– Written and non-written Emacs contribution rules.
– (Well, at least I don’t need to learn how to use git).
Then add a high anxiety level (depends on the personality of course) to this recipe and you’ll get the inability to make any “drive in” contributions 🙂
Summarizing, as a newbie (which would sound odd in many other places after >1year), I found Emacs and infrastructure to be a *high* hanging fruit: it looks nice, it is desirable, but it’s hard to reach and start eating at last.
Hence, I admire the productivity of the Emacs’ maintainers and (often/rare) contributors :thumbs-up:
Thanks for all your work on this, Lars. Dealing with bug reports (particularly old ones) and reviewing patches isn’t as much fun as writing code, but it really does help the project (any project).
Oh, the math for how many open bugs would be left in the absence of new bugs is 0.9**10 🙂
I have to point out the divisive 2016 US election issue: https://www.gocomics.com/bloom-county/2015/10/01
Sounds like checking many of these rules could be automated using some “checkpatch” script. Is this not the case already?
PS: totally agree with Dale about the employer assignment, no way I’m spending days trying to find someone at $BIGCORP who merely understands the question.
I’m an Old Fart. The first text editor I used was on an IBM mainframe. Over the years I moved across and down through minicomputers, super-micros, and finally PCs. I cut my teeth in Unix on AT&T System V Release 2, and had a Unix machine at hose before getting a PC running MSDOS. The Holy War in Unix land was whether Vi or Emacs was the One True Editor for Unix systems.
I remember the days when developers would log into the multi user Unix system that hosted them as a user connecting through a terminal. Some old timers used Emacs, and had it set as their *shell* in their login profile. The did *everything* from within Emacs.
Emacs may be the most powerful editor in existence, but that power comes at a cost. There is a *significant* learning curve, starting with learning to customize it so it behaves as yu9 wish. (I gor Emacs to use WordStar command assignments because a lot of other things I used did too, and I didn’t need to retrain my fingers. “Muscle memory” is critical, and why shifting to a new keyboard can be painful.)
The problem with attracting young developers to submit Emacs patches isn’t the use of git or complicated patch submission rules. It’s getting them to *use* Emacs in the first place, and know enough about it be motivated to create and submit patches.
At the moment, Visual Studio Code seems to be the new hotness. Open source, cross platform, usable out of the box but extensible through JavaScript based addons, and decently crafted versions of what in Emacs would be modes to support specific programming languages with things like syntax highlighting..
Until you have a convincing answer for those younger developers about *why* they need to learn Emacs and *can’t* just use VSC, you will continue to see a lack of younger contributors.,
I admire your work in triaging and fixing Emacs bugs, and I’m glad you are doing it. I remember the days when an outfit called Convex Systems made “baby supercomputers” and one of their engineers talked about closing all outstanding Emacs bugs by replacing the version of Gosling Emacs they included with Gnu Emacs.
Over the years, I’ve been regularly contributing to Wanderlust (I’m the person who moved WL’s fontificatin to font-lock, back around Emacs 23), and at some point I even contributed a minor melpa package. I’ve often had the itch to contribute to Emacs itself, just to realise that I couldn’t be bothered to fill in yet another administrative document (I’ve got enough of these at work).
Does contributing to Emacs still require having documents on file at the FSF?
Yup. (But it’s less work filling out the paperwork now than it used to be.)