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 dus...@redhat.com On Tue, May 3, 2016 at 2:05 PM, Joe Julian <j...@julianfamily.org> 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 >> [2]: https://github.com/gluster/glusterdocs/pull/108 >> > [3]: https://github.com/blog/1986-announcing-git-large-file-storage-lfs > > >> >> _______________________________________________ >> Gluster-devel mailing list >> Gluster-devel@gluster.org >> http://www.gluster.org/mailman/listinfo/gluster-devel >> > > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@gluster.org > http://www.gluster.org/mailman/listinfo/gluster-devel >
_______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel