[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Extensions to M4sh

From: Carlos O'Donell
Subject: Re: Extensions to M4sh
Date: Wed, 4 May 2022 08:54:50 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]