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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
