Hi Karl,
thanks for the detailed answer! I resonate with your concerns. I will
only apply if you and others like Zack and Paul agree. Either say no or
please provide feedback to my proposed text for the program application.
If that means providing patches for open bugs, then great.
That is what is needed.
https://debbugs.gnu.org/cgi/pkgreport.cgi?package=automake
I am pretty sure we can direct them to focus on this.
However, going along with what Paul said, I am skeptical that there is
any real chance that someone from "Neighborhoodie Software" knows or
will learn m4 + sh + perl + etc. enough to actually do anything useful.
I agree that the GNU Buildsystem is complicated and I advice everybody
so seek alternatives. Nevertheless, it can be learned and improved in a
reasonable amount of time.
> improve documentation,
I am equally skeptical that that would happen.
I would love to see any minor improvement, as the documentation left me
puzzled multiple times.
> and reduce technical debt.
I don't know what that means. I instinctively shy away from such
vague buzzwords.
It is a general statement. Nobody wants to rewrite Automake in Rust or
replace M4 by Python ;-)
My interpretation for Autocond and Automake would be to adjust issues
with newer version of the used technologies or adjusting tests to newer
C and C++ standards and the stricter interpretation of modern compilers.
It could also help out on the way to Automake 2.0.
My biggest concern is that I do not want to spend the little time I have
"explaining" to people, who are supposedly there to help, how these
packages work and what the basic approach is. (And I'm sure that all the
rest of us doing the development feel the same way.) I fear that is
exactly what will happen.
Maybe you are right. I cannot counter your fear. Do you feel like not
trying it in the first place?
Kind regards,
Christoph
