Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Documentation updates -- tentative #180

Merged
merged 14 commits into from Oct 14, 2016
Merged

Conversation

jdetter
Copy link
Contributor

@jdetter jdetter commented Sep 20, 2016

I updated a lot of the old README's to support github markdown. I also added stubs for branch statuses at the API level. I will add descriptions for APIs that don't currently have a description.

Not ready for merge.

Copy link
Member

@wrwilliams wrwilliams left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So far so good. Do we want to make these generated files at CMake time? We could sub in the version (consistently), the branch that the README is on (also consistently), and generate some default status info from commit logs. I think at least the version, and possibly the active branch, would be useful to auto-gen; the status may or may not be a win, but should be easy enough to try.

@jdetter
Copy link
Contributor Author

jdetter commented Sep 20, 2016

@wrwilliams Do you mean generate all of the READMEs in the API directories at CMake time, or just the status information?

@wrwilliams
Copy link
Member

I meant start with template README.md.in files living with our version.h.in and fill in version, branch, status information at CMake time.

@jdetter
Copy link
Contributor Author

jdetter commented Sep 20, 2016

Do we still want to keep the generated READMEs in the repository? It might be nice for the users to be able to view the READMEs on github where the markdown is rendered.

@wrwilliams
Copy link
Member

Yes, that was in fact the idea: make what the users see automatically generated. If we rely on manual updates for that we're asking for trouble.

Of course, we're also asking for trouble on merges unless we can add a merge hook that regenerates the appropriate readmes for the target branch; this seems like it's opening a few cans of worms. We should discuss options for making this problem tractable and automatic, and then talk to @n738cu about how we want to move forward--as a manual thing I'm 90% confident that anything other than a uniform branch status block that stays everywhere will be more trouble than it's worth.

@jdetter
Copy link
Contributor Author

jdetter commented Sep 21, 2016

I agree that if we leave branch statuses all over the place then people aren't going to update them and they will just be confusing to our users because they will be out of date. Maybe just a short notes section in each API is sufficient? During the meeting before last Bart was pretty adamant about having branch statuses at the API level but now it looks like it might be more trouble then it's worth.

@wrwilliams
Copy link
Member

Regardless of automation, is there anything here that we shouldn't merge over?

@jdetter
Copy link
Contributor Author

jdetter commented Oct 14, 2016

No I think everything here is fine now. All of the READMEs now support github syntax so they should now be rendered properly.

@wrwilliams wrwilliams merged commit de2c2fb into master Oct 14, 2016
@mxz297 mxz297 deleted the release9.2/fixes/documentation branch January 31, 2019 15:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants