That was the other thought I had, but I wasn't going to volunteer to
change the existing presos. :D
On 05/03/2016 11:14 AM, Dustin Black wrote:
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
[email protected] <mailto:[email protected]>
On Tue, May 3, 2016 at 2:05 PM, Joe Julian <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
http://www.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
[email protected] <mailto:[email protected]>
http://www.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
[email protected]
http://www.gluster.org/mailman/listinfo/gluster-devel
