https://lars.ingebrigtsen.no/2021/08/14/10x10/ Skip to content Random Thoughts The Sky Won't Fall? Menu and widgets [haunted-300x200] About Lars Ingebrigtsen Recent Posts * The Best Greatest Albums of All Time Ever * 10x10% * PX87: The Fun House * PX91: With Love From Hell & Greetings From Hell * PX01: Skin Deep * PX92: Skin Deep * PX86: Raw #8: The Graphic Aspirin for War Fever * TSP2018: Women Make Film: A New Road Movie Through Cinema * TSP1986: Caprice * TSP2017: Tania Libre Featured RSS Recent Comments * 10x10% by Dale * 10x10% by Adam * 10x10% by larsmagne23 * 10x10% by Dima * PX92: Skin Deep by larsmagne23 * PX92: Skin Deep by logereborn * TSP2020: The Human Voice by larsmagne23 * TSP2020: The Human Voice by YE * PX96: Julius Knipl, Real Estate Photographer by Scipio Garling * PX89: Akbar and Jeff's Guide to Life by Life in Hell - This isnt happiness Movies The World Tilda Swinton Ingmar Bergman Moving Pictures Comics Fantagraphics Eclipse Comics Pacific Comics Epic Comics Vortex Elaine Lee Renegade Archives Archives [Select Month ] Now Playing Categories * 1939 * 1995 * 4AD * A&R * animals * baking * bd80 * Bergman * bistro * books * bookvember * Carpenter * cccb * century * comics * computers * consumerism * cooking * couture * daze * Decade * Elaine Lee * Emacs * fantagraphics * food * furniture * gadgets * gmane * Hellraiser * holiday * horticulture * linux * live * movies * music * mysteries * Netflix * New Music * No Comment * OTB * programming * Punk Comix * review * rocktober * rockvember * The World * Tilda Swinton * vortex Search for: [ ] [Search] 10x10% [2021-08-14] 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: [2021-08-14-3] 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. [2021-08-14-4] This last 10% stretch started July 13th at 2820 open bugs, and we're down to 2690 today. [2021-08-14-5] And 50% of issues are closed within a week, which isn't too bad. [2021-08-14-6] The rate of bugs reported seems to be roughly linear over the years. [2021-08-13] 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". [2021-08-12] 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: [2021-07-22] 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: [P1740005-scaled] 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. [2021-08-11] 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? [2021-08-12-1] 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. [2021-08-12] 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. [2021-08-12-4] 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. [2021-08-12-2] 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.) [2021-08-12-3] And this is people contributing one patch per month. I think we're on the right track here? At least it seems hopeful. [2021-08-14-1] 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. [2021-08-14-2] 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. Share this: * Twitter * Facebook * Reddit * Like this: Like Loading... Related Articles Posted on August 14, 2021August 14, 2021Author larsmagne23Categories Emacs 4 thoughts on "10x10%" 1. [b194c9] Dima says: August 14, 2021 at 17:39 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. Reply 1. [4c2f47] larsmagne23 says: August 14, 2021 at 17:46 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.) Reply 2. [ddd237] Adam says: August 14, 2021 at 19:38 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. Reply 3. [cef73c] Dale says: August 14, 2021 at 20:36 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! Reply Leave a Reply Cancel reply Post navigation Previous Previous post: PX87: The Fun House Next Next post: The Best Greatest Albums of All Time Ever Proudly powered by WordPress %d bloggers like this: