That wasn't my personal experience (with the setup-related ones), but
admittedly it's a tiny sample.
Dude, I'm still running a 2004-era distro on one of my desktop boxes!
Sure, that's unusual, but ancient servers in production definitely
aren't. The more you have, the harder it is to validate and move to
a new version. You've got, what, a few hundred servers to worry about?
We've got a few hundred thousand. (Not all Hadoop-related, I mean, just
in general.) I have no idea what the overall mix is, but I was aware of
both RHEL 5.x and 4.x subsets up until fairly recently (the latter also
being 2004-era; the former more like 2007, I think), and I wouldn't be
surprised if there were still *BSD boxes lurking somewhere. I don't
think there are any RHEL 6.x yet.
So no, OS-related docs don't get stale that quickly, at least not for
some of us.
Not at all. It's simply a statement that those working most closely with
the code and XML configs--i.e., those who do watch JIRAs and the mailing
lists religiously--are more likely to keep things updated if they're
nearby/noticeable. We all have limited attention-hours to devote to
maintenance, so anything that makes it easier, faster, or more likely to
happen is a Good Thing.
And I know you're aware that the default state for documentation is
"nonexistent." Especially where developers are concerned.
(Btw, wasn't there a recent suggestion to automatically pull config keys
and descriptions out of the foo-default.xml files and publish them? With
something like that in place, the docs you want would fall out of this
and similar patches immediately. One of my mottos for the last few years
has been, "if it can be automated, it should be automated.")
I guess this has drifted a bit; perhaps further discussion should go to
one of the lists?