We had considered what Benjamin proposes (I think I even wrote the
code to do it), but we decided it was better to commit them back since
all of the other documentation is in the docs folder and is checked
in. I don't have a strong opinion either way though, so I'm fine with
not commtting them
+kevin for context
When we approached this problem there were a few routes we could take. One
approach we were leaning towards was to allow the help information to be
specified directly in markdown rather than in C++. Markdown would be the
only source of help information, and the C++ code calling
Thanks Neil. Pushed 54339eb0e934e120e5cb5e693681679dea24b2d2. It also
includes an update induced by slave->agent rename.
I think we eventually should do what Benjamin suggests. It's hard for a
human to remember, when a certain script should be run (even though having
a script is a huge
Hi,
the way one currently has to manually regenerate markdown outputs which should
then be checked in together (and ideally: atomically) with the corresponding
source changes seems to be a reoccurring source of friction.
I understand that being able to e.g., reference the generated markdown
When modifying the endpoint help text, we should remember to update
the generated help files (via support/generate-endpoint-help.py) --
the changes to both the input text and generated output files should
be included as part of the same commit.
Neil
On Wed, May 18, 2016 at 10:58 AM,
