GNOME Bugzilla – Bug 699998
avoid huge and growing number of rendered videos in git
Last modified: 2018-03-28 13:16:04 UTC
It is starting to be a showstopper to keep on adding the rendered webm files directly into the source tree. I think the autogunk should by default wget the rendered webm files from somewhere I'll render them to and optionally with a configure switch (--render) use blender to render them locally.
I don't think this is a viable plan because we cannot rely on people having internet access so the videos should be in the package. Also, the video is shown every time a new account is logged into and GNOME currently does not have the infrastructure for this (although it could possibly be created). What exactly is the "showstopper" here?
(In reply to comment #1) Misunderstanding. Tarballs and packages would remain having the webms in. The showstopper is growing number of translated videos, 2megs each, treated like source they aren't. They don't belong to source control, making everyone and the infrastructure suffer from data bloat.
(In reply to comment #2) The correct fix appears to be to update the make rules to generate the translated/rendered videos when creating a tarball. This will mean that blender would be needed to build the docs. I checked the README, and it already appears to be mentioned: https://git.gnome.org/browse/gnome-getting-started-docs/tree/README#n38
In order to have all the webms in released tarballs, we will probably have to tweak the autogen.sh script to wget available webm files from an external repo/storage. A viable long-term plan appears to be having a build server that would render C as well as translated videos for us.
We'll need a better canonical location for these, but for the sake of testing, I've uploaded and rsync the videos to http://jimmac.fedorapeople.org/gnome3/getting-started/
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-getting-started-docs/issues/2.