Young folks: Please can we contribute using modern git-based workflow rather than email?
Old farts: No.

👶: OK, but can we at least use modern memory-safe languages?
👴: Also no.

👶: Perhaps we could modernise our language & attitudes to be more inclusive?
👴: LOL! No.

👶: Could we at least consider addressing some long-standing community issues?
👴: What part of "no" are you having trouble understanding?

⏳ ⌛

👴: Why aren't there any new people contributing to our project? Truly a mystery. 🙃

@Edent Please can we use modern build tools like cmake, ninja, etc etc

Hell no. Plain `make` does the job easily for 90% of projects. Rtfm and learn how to use it before you go pushing for the latest flavor of the month.

Joining an existing project requires learning how it already works. You don't get to just jump in and imnediately request every current developer change all of their established procedures to accommodate you. That won't fly, anywhere in the world.

@hyc I have literally no idea what you're talking about, sorry.

@hyc @Edent You're behaving like one of the old farts he's talking about and you just made his point for him.

Being inflexible and pushing the status quo is exactly how projects die.

@soviut @Edent yes, I understood his point. But if you fail to acknowledge the validity of "if it ain't broke don't fix it" then you've got problems too. Nobody wants to spend time reinventing wheels. Changing tooling has a high cost. If your first instinct as a new developer to a working project is "we gotta upgrade to tools I'm more comfortable with" instead of "I need to learn how this stuff works" then you've got an attitude problem.

@hyc @soviut @Edent Howard, you've accidentally entered this discussion without understanding that this is a subtoot of a particularly venomous exchange going on in the linux community right now that has nothing to do with makefiles or build scripts.

You .. might have a better reception in this thread if you take a moment to look at the resignations of Hector Marcan and Karol Herbst so that you understand the context well enough to formulate an informed comment.

@hyc @Edent If a project is having trouble attracting new talent, then something IS broken and DOES need fixing. If you are unable to maintain a decent DX in your project, that's an important aspect that's broken.

Just because the "old farts" are used to the hostile environment doesn't mean the environment isn't hostile.

Senior maintainers need to be introspective, identify their negatives and correct them. Otherwise they risk their projects being ignored to death.

@soviut @Edent if a project retools to accomodate every newcomer it'll be spending all its time rearranging deck chairs instead of advancing whatever it meant to do.

@hyc @Edent Nobody said it's retooling to accommodate every newcomer and you know that; don't be disingenuous.

It's about staying reasonably current so that stuff people are learning in school, in bootcamps and online in the last decade is actually applicable. Otherwise all that talent slips by as they go towards more nimble projects.

Keeping a toolchain reasonably up to date is NOT a full time job and you know that too. It isn't even something you need to do; let the new blood who want it handle it for you.

I am in disbelief that you think Howard might need to grow a clue, or that his projects might be at risk of dying, where of any of the code bases I downstream for MacPorts, Howard's (e.g. https://ports.macports.org/port/lmdb/details/) have by far more users, like by a factor of almost 8X the next highest ranked MacPort for which I am a maintainer (e.g. https://ports.macports.org/port/openssh/details/).

Maybe, you don't understand how projects actually thrive? It sure as heck isn't with navel gazing about old farts not understanding new generations.

Admittedly, I am still upset that MacPorts recently lost kencu (Ken Cunningham who was doing work maintaining various gcc versions among other things for OS X Tiger and such) because some disrespectful jerk (who had maybe two commits, in something related to NodeJS/NPM I guess?) was insanely rude to him on a public mailing list. I think the rude person got banned, but the damage had been done.

We are blessed to stand on the shoulders of those who did the hard work that makes our lives easier.

More young upstarts would be wise to not it.sh on such shoulders.

Or as Ice Cube phrased it: "Pump your brakes, respect your elders." (from "Can You Dig It" https://www.youtube.com/watch?v=NVRoTyZU4RU)

CC: @[email protected] @[email protected]
lmdb | MacPorts

@teajaygrey @hyc @Edent I didn't say that. I'm remarking that his response to Edent's criticism of project gatekeeping is exactly the attitude that drives away new people from joining the project.

@hyc @Edent what makes Make "plain" and cmake or ninja "flavor of the month", aside from your familiarity bias?

If you are starting software development from scratch, ninja or meson or cmake can make a lot more sense to you than gnu make.

cmake has existed since 2000 (and been used by e.g. kde since 2006), ninja has existed since 2012 - that's 13 years - and meson has existed since 2013; meson/ninja are used for such minor projects as GNOME and Chrome.

perhaps rethink your "month" definition.

@hyc @Edent this is not a post about random first-time contributors demanding an overhaul of the existing workflow and system, it's a post about existing contributors—those who are already familiar with the established workflows—providing constructive feedback and being ignored or driven out