Log in
Tim Retout: In memoriam commit-email.py
I have proposed the deletion of an obsolete script, but it makes me feel complicated feelings so I’m going to try and express those. This particular script was written in 2014, but the concept goes back much further – before git was invented.
When I started university in 2003, I seem to remember the computing society used to run tutorials for first-year students on how to use Apache Subversion for your group project – a vast upgrade on CVS (or worse, no version control at all). Back then, the idea of viewing your changesets in a web browser was relatively new – while it was possible to look at an SVN repository through a web UI, features were limited unless you installed something compicated like Trac.
Figure 1: Data flow when distributing commits via a mailing list
Perhaps because reading email on your desktop computer (I don’t think I could afford an IBM ThinkPad?) was the only vaguely real-time notification system available at the time (except I guess SMS, which cost 10p per text), a common pattern seemed to be to use a post-commit hook to send every single commit to a mailing list, named something like ‘foo-commits’. Indeed, for a long time Fedora had an scm-commits list which appears to be a topic of recent discussion.
I can’t really explain why people wanted to have every commit sent to a mailing list except as a way of getting notified of activity – I can’t believe people would import raw patches from those lists, ala LKML, rather than run actual version control commands to fetch the new source directly. Maybe you’d have to go back to NNTP for this.
I do like the vendor-neutrality of the “everything-as-text” approach, building on the open ecosystem of SMTP. But I doubt we’d see a widespread resurgence of commit lists now – most code hosting must allow anyone to subscribe to email notifications, I assume, and I don’t see a huge benefit in a mailing list archive of commit messages.
In the case of seL4, I’m even more confused about why this script was committed in 2014, shortly after the kernel was put on GitHub. I can only assume it was imported from previous infrastructure. I do know that the implementation is quite Python 2 heavy, with the conversion between unicode and bytes featuring heavily. So rather than risk breaking its logic with patching, I think it’s time to “thank it for its service” and let go.
