<div dir="ltr">Hi all, <div><br></div><div>So we have a new <a href="http://slideshare.net" target="_blank">slideshare.net</a> account, GlusterCommunity (<a href="http://www.slideshare.net/GlusterCommunity/" target="_blank">http://www.slideshare.net/GlusterCommunity/</a>) that connects with the Gluster.org G+ community - and it'll even connect with the YouTube channel! </div><div><br></div><div>I've submitted a PR to the glusterdocs repo that will need some review: it removes all of the presentations from the repo and links to slideshare. (<a href="https://github.com/gluster/glusterdocs/pull/109">https://github.com/gluster/glusterdocs/pull/109</a>) </div><div><br></div><div>In no way does this mean that anyone needs to use Slideshare to host PDFs of slides, you can use whatever you want. I chose slideshare because there was an older Gluster account that had some Gluster.com presentations and it links with YouTube. </div><div><br></div><div>Thoughts? </div><div>- amye </div><div><br></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 12, 2016 at 7:49 PM, Niels de Vos <span dir="ltr"><<a href="mailto:ndevos@redhat.com" target="_blank">ndevos@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5">On Thu, May 12, 2016 at 03:55:23PM +0530, Kaushal M wrote:<br>
> On Thu, May 12, 2016 at 1:25 PM, Niels de Vos <<a href="mailto:ndevos@redhat.com">ndevos@redhat.com</a>> wrote:<br>
> > On Thu, May 12, 2016 at 02:56:52AM -0400, Prashanth Pai wrote:<br>
> >><br>
> >><br>
> >> > > Right now, even cloning the main docs branch is a huge pain due to the size<br>
> >> > > of the repo.<br>
> >> > > I think that branching will solve not this problem, and might make the<br>
> >> > > problem worse.<br>
> >> ><br>
> >> > Branching would not increase the size of the repository itself. Only the<br>
> >> > size used on RTD will be bigger as the HTML for different branches will<br>
> >> > be generated (so contents is there 2x). Cloning the repository is not<br>
> >> > affected.<br>
> >> ><br>
> >> > Deleting files (like the presentations) will also not remove them from<br>
> >> > the git repository. It will stay possible to checkout an older version<br>
> >> > of the docs from the same repository, all of the history is downloaded<br>
> >> > once the repository is cloned.<br>
> >> ><br>
> >> > In order to reduce the size of the repository, you need to create a new<br>
> >> > one, and import the changes without the big files. While importing<br>
> >> > changes from an other (the current) repository, it is possible to modify<br>
> >> > the changes on the fly and prevent importing the big files. This keeps<br>
> >> > the history and the credits for the contributors.<br>
> >><br>
> >> This is an alternative solution:<br>
> >> <a href="https://rtyley.github.io/bfg-repo-cleaner/" rel="noreferrer" target="_blank">https://rtyley.github.io/bfg-repo-cleaner/</a><br>
> ><br>
> > Right, I was thinking about git-filter-branch. In the end, I am pretty<br>
> > sure that the old/original repository is not valid anymore. I expect<br>
> > that 'git rebase' is used for the cleaning, and that will change the<br>
> > commit-ids of patches that follow after a 'cleaned' patch.<br>
> ><br>
> > Mu recommendation for a seperate repository, is only for preventing<br>
> > inconsistencies between the upstream repository (after cleaning) and the<br>
> > previously cloned/forked repositories that contributors have.<br>
> ><br>
> >> > Where would you suggest the presentations (and other files?) should get<br>
> >> > located?<br>
> >><br>
> >> May be an official Gluster community slideshare or speakerdeck account ?<br>
> ><br>
> > Possibly something like this. But we should have a plan for the existing<br>
> > presentations too. And we have to accept that not everyone presenting<br>
> > about a Gluster (related) topic will use 'our' SaaS instance.<br>
> ><br>
> >> Git LFS is also also an option but we don't really need versioning for<br>
> >> presentation files. Git LFS will keep large files in a separate location<br>
> >> and keep a "pointer" to those in the repo.<br>
> ><br>
> > I'd prefer something like this. Most of my presentations are written<br>
> > while I'm travelling, so a connected service is not really an option for<br>
> > me in any case.<br>
><br>
> The docs repo should just have links to the presentations.<br>
> They could be hosted on slideshare/speakerdeck, google drive or they<br>
> could be hosted html5 presentations.<br>
> If required we could just host the presentations on <a href="http://download.gluster.org" rel="noreferrer" target="_blank">download.gluster.org</a>.<br>
> I've seen it being used to host resources for tutorials previously<br>
> (like disk images),<br>
> so hosting the actual presentations shouldn't be too hard.<br>
<br>
</div></div>I really do not care where they are hosted. We just can not demand the<br>
use of a SaaS for them. We can offer the option of course, but still<br>
allow presenters to use the tool of their preference.<br>
<span class=""><font color="#888888"><br>
Niels<br>
</font></span><br>_______________________________________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a><br>
<a href="http://www.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://www.gluster.org/mailman/listinfo/gluster-devel</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Amye Scavarda | <a href="mailto:amye@redhat.com" target="_blank">amye@redhat.com</a> | Gluster Community Lead</div></div>
</div></div>