I've been toying with maintaining presentations in asciidoc format, which lends itself better to revision control and allows me to auto-publish to multiple formats relatively easily.
Dustin L. Black, RHCA
Principal Cloud Success Architect
Red Hat, Inc. - Strategic Customer Engagement
(o) +1.212.510.4138 (m) +1.215.821.7423
dustin@xxxxxxxxxx
On Tue, May 3, 2016 at 2:05 PM, Joe Julian <joe@xxxxxxxxxxxxxxxx> wrote:
On 05/03/2016 05:43 AM, Nigel Babu wrote:
Hello folks,
I've just started this week at Red Hat. Over the next year or so, I'll be helping with cleaning up the existing CI pipeline and improving it so that we have much better confidence with releases.
Amy has been helping me get an overview of the infrastructure we have and we decided to put this on readthedocs under Ops Guide[1], considering we'd like to be open about our infra. While writing this, I also noticed there were quite a few warnings from mkdocs about dead links. I've taken a few minutes to fix them up as well[2]. If anyone has a few minutes, I'd be extremely grateful if you could merge them both.
Additionally, I notice that we have presentations on the docs git repo, which makes it burst up in size to 145 MB. This makes for a unpleasant experience cloning the repo. If we don't clone the repo, we're less likely to see the warnings from mkdocs about deadlinks and might also turn away potential contributors. If possible, I'd like to propose that the presentations be hosted elsewhere and be linked from the documentation site (without breaking existing URLs). I'm also happy to host it on a separate git repo that is exclusively used for presentations. Does anyone have any strong opinions on the matter?
I talked a long time ago about trying to have a repo for presentations. Some generic ones that could be used by a "speaker network" was something we once tried to put together.
Either way, whether they stay attached to the documentation (I agree they shouldn't) or they're moved into a new repo, it should use large file storage[3] to keep the repo size reasonable.
[1]: https://github.com/gluster/glusterdocs/pull/107[3]: https://github.com/blog/1986-announcing-git-large-file-storage-lfs
[2]: https://github.com/gluster/glusterdocs/pull/108
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
