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