For about the last year, I've been the main person applying bug fixes to (or at least reading bug reports for) Automake. My pace has been quite slow, but since maintenance was almost completely lacking for some years before that, I've been doing what I could. Mainly, going through the old bug reports and dealing with the "easy" ones, besides trying to handle new ones as best I can. There are still many outstanding bug reports that I have not even read.
Unfortunately, I am going to have even less time for Automake for the foreseeable future. I will still do what I can, but it will not be much. Therefore, if you have some automake/perl/shell/make/etc. development skill or interest, and are also interested in Automake maintenance continuing, please volunteer if you can. I recommend starting by looking at the open bug list: https://debbugs.gnu.org/cgi/pkgreport.cgi?package=automake#_0_4_4 FWIW, I knew essentially nothing about the Automake implementation when I started, and still don't know much. To begin, I read the setup info available in the repository, asked questions of friends and lists when needed, got a build working and did some easy reports (e.g., tweak the manual), and went from there. It all takes considerable time; there is no royal road, as far as I know. Jim Meyering remains the official maintainer of Automake, and rolled out the couple of point releases we did in the last year. (Thanks Jim.) But he has so many other responsibilities that day-to-day maintenance for Automake has to take a back seat. Hence the need for more volunteers to help. Best, Karl P.S. FWIW, in the bug list, I have been marking as "confirmed" the bugs which are real, but which I myself can't or don't want to fix any time soon, for whatever reason. Of course it would be great if anyone else takes any of them up. P.P.S. Of course us volunteers get to choose our own aims and priorities -- I personally have no interest in "automake-ng" or any other major development or change to Automake. My goal was and is to keep the existing program that has served so well for so many years viable and maintained. Retaining compatibility, i.e., not breaking existing Makefile.am/configure.ac's, was and is always my top priority. Again, FWIW.