Right, but your parent is saying that job is not some new "DevOps" thing, it is just well functioning operations. "DevOps" is meant to evoke bi-directional buy-in and cooperation between the people working on development and the people working on operations. Re-naming the operations role "DevOps" doesn't get you that - you could still have low buy-in and poor cooperation between development and "DevOps".
I agree, and I agreed with that previous comment and the one before it. But I don't see where the comment I replied to made any reference to the name not doing what it says. I only see him saying that what we call DevOps existed before we called it that.
In any case, of course the name doesn't cause buy-in to happen, just like hiring an "Engineer" doesn't mean the person will do a good job engineering.
You're not saying that we should avoid a term meant to evoke the idea that cooperation is expected, because it might not happen, are you? I can only see rightness in trying to be clear about what's expected and naming roles to suggest positive cooperation is part of the job. If "DevOps" is meant to suggest buy-in and cooperation, you've convinced me that it's a better description than whatever it was called before.
I am saying that using the "DevOps" term for a role undermines the effectiveness of the term as a definition of culture. "I'm just a developer, I don't need to worry about this DevOps stuff, that's what we have the DevOps engineers for!"
He's not saying that chef and puppet are different because they're new; he's saying that using chef and puppet and docker all day long is a different job than debugging CSS and JavaScript or implementing REST api in scala all day long.