On 5/3/22 16:35, Zack Weinberg wrote: > On Mon, May 2, 2022, at 2:30 AM, Paul Eggert wrote: >> On 5/1/22 19:06, Alex Ameen wrote: >>> Whoever is most actively working on M4sh would be an incredibly >>> useful contact for me, so if "that's you" let me know. >> >> To be honest right now I think "that's you" is the correct answer. >> As in, you're the one. > > I concur. Right now it seems like nobody is actively working on > anything in Autoconf, so if you've got patches that makes you the > most active contributor. > > I am probably the person who most recently _worked_ on m4sh and I > would be happy to review the patches you have. > >> If these are extensions to m4sh (as opposed to changes) and would >> be useful outside libtool it sounds like Autoconf would be a good >> home for them, whatever they are. > > The trickiest thing here is probably going to be release management. > I certainly wouldn't mind turning the crank on an autoconf 2.72 that > just had the m4sh improvements + whatever other patches have been > committed since 2.71, if that would make your life easier; however, > presumably you don't want to make libtool N+1 _require_ the > hypothetical autoconf 2.72, so you will need to carry the > improvements yourself for a while, and we'll have to coordinate > changes between both copies. Why do you consider release management tricky here? What if we did require tighter coupling? Downstream distributions should be helping here if there are testing issues with integrating new autoconf, automake, libtool, m4 etc. In Fedora we are preparing for a future we can turn the crank on this faster. -- Cheers, Carlos.
