That's a really good idea. Automake and Autotools in general underpin a fair amount of key open source software, but is taken for granted.
Ideas for making the case for funding: identify... - how many commonly used Debian/Ubuntu/Alpine packages and/or GitHub projects rely on automake/Autotools - markers of risk (e.g. very out of date or buggy embedded Autotools files) - problems this has caused in the past - related government standards for software quality All of that might help make the case. Another related idea: a couple years ago I helped https://github.com/zlib-ng/zlib-ng clean up a build mess. zlib is key infrastructure that had become nearly unmaintained (although Mark has since stepped up maintenance (Hi Mark!)). After trying and mostly failing to help zlib, I switched to the more active zlib-ng. They had two build systems: a non-autotools configure script, and cmake. (They still do; some users have very strong opinions for and against cmake.). My contribution was to get their CI to verify the two build systems produce identical results across a variety of conditions (see https://github.com/zlib-ng/zlib-ng/blob/develop/test/pkgcheck.sh ) and fix the few problems that found. This experience suggests that it might be worth updating the embedded Autotools files of a very small number of core projects, possibly also adding reproducible build tooling to avoid breaking them in the process, as I did with zlib-ng. This is a much larger effort, so maybe just one or two packages merit it for starters. Good luck! - Dan On Thu, Jun 6, 2024, 6:09 AM Christoph Grüninger <f...@grueninger.de> wrote: > Hi Karl, > given Automake is facing a lack of contributors and still being an > important part of software like GCC or LibreOffice, we should reach out > for help! > > The German Sovereign Tech Fund offers a Bug Resilience Program [1]. They > offer "Direct Contributions", i.e.: > > Our partner 'Neighbourhoodie Software' provides a variety > > of types of contributions to participating projects to > > address known issues, improve documentation, and reduce > > technical debt. Very often, FOSS projects maintainers > > know that certain parts of critical technologies on > > which they work contain vulnerabilities or security > > deficiencies. However, the maintainers may not have the > > capacity to deal with them yet […]. > > I think Automake fulfills the formal criteria. If you want, I can apply > for Autotools. We can discuss this here or off-list. > I am a German citizen and I would love to see Automake / you helped over > where my tax-payer money is usually spent. > > [1] https://www.sovereigntechfund.de/programs/bug-resilience > > Bye > Christoph > > > Am 15.05.24 um 03:18 schrieb Karl Berry: > > Hi Christoph, > > > > end of 2023 you shared the news that automake release 1.17 could > happen > > > > Indeed. Unfortunately since then I have had to attend to other priority > > projects, and there's no one else driving automake. I hope to be able to > > spend some time on automake again soon to bring the release to fruition. > > I have no ETA though, as ever. Sorry. > > > > There has been no public communication for the last couple of > > weeks. > > > > Well, I (or someone) is still replying to questions and bugs on > > automake@gnu.org and bug-autom...@gnu.org. Not about the release, > > though, granted. > > > > What are your plans regarding 1.17? > > > > Release as soon as possible. > > > > Are there blockers? > > > > Yes. The last pretest in December turned up at least one: > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=68808 > > > > It requires hacking a function in sanity.m4 to probe make for its > > "subsecond mtime" behavior. > > > > There may be others, I'd have to look at the recent pending bugs. > > > > Is there anything we as the community can help? > > > > Well, a patch for the bug above would certainly be helpful. > > > > Patches in general for any other bugs, especially the recent ones, would > > be all to the good. > > > > Other than actual patches, reviewing the other recent pending bugs to > > see if any others are important enough to require fixing before the > > release, or simple enough to just fix and be done with it, would also be > > helpful. (I know there are a few other patches simply waiting for me to > > review and install.) > > > > Beyond that, three years ago I wrote a message requesting more > > volunteers. The information is (sadly enough) still current: > > https://lists.gnu.org/archive/html/automake/2021-03/msg00018.html > > > > Thanks, > > Karl > > > > P.S. BTW, did something happen somewhere that prompted you to send this? > > I ask because another person wrote me off-list today with the same > > question. Seems a bit much for coincidence. > >
