This person also maintains GNU readline, the thingy that lets you hit Ctrl-R in a shell prompt in most shells: https://tiswww.case.edu/php/chet/
If ever there were a demonstration of how some of the most-used open-source software in the world is maintained by a small group of tireless people, it would be this. (I’ll spare you the xkcd link.)
A lot of GNU projects built their processes when revision control systems were not widespread and when moves between revision control systems lost a lot of data. They generally prefer to maintain a ChangeLog file, rather than git history. In the distant past, I had an exciting pile of XSLT that would extract my svn commit message and the list of files that were changed from svn’s XML export, convert it into the GNU ChangeLog file format, and then add a new commit with the ChangeLog entry for the previous commit.
Sure, but at this point most other high-profile GNU projects (glibc, emacs, coreutils, grep, gcc, binutils, gnulib, …) have adopted a more modern development style of fine-grained commits with descriptive commit messages. The bash repo remains something of an anachronism, unfortunately.
A reminder that Bash seems to be mostly (entirely?) maintained by one person: https://git.savannah.gnu.org/cgit/bash.git/log/
This person also maintains GNU readline, the thingy that lets you hit Ctrl-R in a shell prompt in most shells: https://tiswww.case.edu/php/chet/
If ever there were a demonstration of how some of the most-used open-source software in the world is maintained by a small group of tireless people, it would be this. (I’ll spare you the xkcd link.)
Very true, and another interesting data point is that the initial author of bash Brian Fox was the first employee of the FSF.
I believe they could find volunteers for GCC, emacs, coreutils, etc., but nobody wanted to write a shell :-P
So they paid someone to do it, and then Chet Ramey took over a few years later and has maintained it for decades
There’s something about shells that make it undesirable to work on, though I certainly like it :)
Is there any code review or other oversight about what gets merged and, if so, how does that work?
Or is it literally just one maintainer making all the decisions?
Eg, what if the maintainer wanted to add a new feature?
There is a patch based workflow using the bug-bash@ mailing list. I don’t think any other review system exists.
The git log of bash is still mostly useless :(
A lot of GNU projects built their processes when revision control systems were not widespread and when moves between revision control systems lost a lot of data. They generally prefer to maintain a ChangeLog file, rather than git history. In the distant past, I had an exciting pile of XSLT that would extract my svn commit message and the list of files that were changed from svn’s XML export, convert it into the GNU ChangeLog file format, and then add a new commit with the ChangeLog entry for the previous commit.
Sure, but at this point most other high-profile GNU projects (glibc, emacs, coreutils, grep, gcc, binutils, gnulib, …) have adopted a more modern development style of fine-grained commits with descriptive commit messages. The bash repo remains something of an anachronism, unfortunately.
Honestly, Changelogs should be for user-relevant changes, which commits might not necessarily be