On Tue, May 17, 2016 at 02:42:27PM +0530, Amye Scavarda wrote: > Hi all, > > So we have a new slideshare.net account, GlusterCommunity ( > http://www.slideshare.net/GlusterCommunity/) that connects with the > Gluster.org G+ community - and it'll even connect with the YouTube channel! > > 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. ( > https://github.com/gluster/glusterdocs/pull/109) Cool, but note that the size of the repository does not decrease with that commit. The git repository will still contain all the presentations in the history/log. But not adding any more presentations is a good step already :-) > 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. > > Thoughts? Looks good to me, but maybe you can address this comment in the GitHub pull request: https://github.com/gluster/glusterdocs/pull/109/files#r63498585 Thanks, Niels > - amye > > > > On Thu, May 12, 2016 at 7:49 PM, Niels de Vos <ndevos@xxxxxxxxxx> wrote: > > > On Thu, May 12, 2016 at 03:55:23PM +0530, Kaushal M wrote: > > > On Thu, May 12, 2016 at 1:25 PM, Niels de Vos <ndevos@xxxxxxxxxx> wrote: > > > > On Thu, May 12, 2016 at 02:56:52AM -0400, Prashanth Pai wrote: > > > >> > > > >> > > > >> > > Right now, even cloning the main docs branch is a huge pain due > > to the size > > > >> > > of the repo. > > > >> > > I think that branching will solve not this problem, and might > > make the > > > >> > > problem worse. > > > >> > > > > >> > Branching would not increase the size of the repository itself. > > Only the > > > >> > size used on RTD will be bigger as the HTML for different branches > > will > > > >> > be generated (so contents is there 2x). Cloning the repository is > > not > > > >> > affected. > > > >> > > > > >> > Deleting files (like the presentations) will also not remove them > > from > > > >> > the git repository. It will stay possible to checkout an older > > version > > > >> > of the docs from the same repository, all of the history is > > downloaded > > > >> > once the repository is cloned. > > > >> > > > > >> > In order to reduce the size of the repository, you need to create a > > new > > > >> > one, and import the changes without the big files. While importing > > > >> > changes from an other (the current) repository, it is possible to > > modify > > > >> > the changes on the fly and prevent importing the big files. This > > keeps > > > >> > the history and the credits for the contributors. > > > >> > > > >> This is an alternative solution: > > > >> https://rtyley.github.io/bfg-repo-cleaner/ > > > > > > > > Right, I was thinking about git-filter-branch. In the end, I am pretty > > > > sure that the old/original repository is not valid anymore. I expect > > > > that 'git rebase' is used for the cleaning, and that will change the > > > > commit-ids of patches that follow after a 'cleaned' patch. > > > > > > > > Mu recommendation for a seperate repository, is only for preventing > > > > inconsistencies between the upstream repository (after cleaning) and > > the > > > > previously cloned/forked repositories that contributors have. > > > > > > > >> > Where would you suggest the presentations (and other files?) should > > get > > > >> > located? > > > >> > > > >> May be an official Gluster community slideshare or speakerdeck > > account ? > > > > > > > > Possibly something like this. But we should have a plan for the > > existing > > > > presentations too. And we have to accept that not everyone presenting > > > > about a Gluster (related) topic will use 'our' SaaS instance. > > > > > > > >> Git LFS is also also an option but we don't really need versioning for > > > >> presentation files. Git LFS will keep large files in a separate > > location > > > >> and keep a "pointer" to those in the repo. > > > > > > > > I'd prefer something like this. Most of my presentations are written > > > > while I'm travelling, so a connected service is not really an option > > for > > > > me in any case. > > > > > > The docs repo should just have links to the presentations. > > > They could be hosted on slideshare/speakerdeck, google drive or they > > > could be hosted html5 presentations. > > > If required we could just host the presentations on download.gluster.org > > . > > > I've seen it being used to host resources for tutorials previously > > > (like disk images), > > > so hosting the actual presentations shouldn't be too hard. > > > > I really do not care where they are hosted. We just can not demand the > > use of a SaaS for them. We can offer the option of course, but still > > allow presenters to use the tool of their preference. > > > > Niels > > > > _______________________________________________ > > Gluster-devel mailing list > > Gluster-devel@xxxxxxxxxxx > > http://www.gluster.org/mailman/listinfo/gluster-devel > > > > > > -- > Amye Scavarda | amye@xxxxxxxxxx | Gluster Community Lead
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
