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)
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?
- amye
On Thu, May 12, 2016 at 7:49 PM, Niels de Vos <ndevos@xxxxxxxxxx> wrote:
I really do not care where they are hosted. We just can not demand theOn 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.
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
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
