Merge all GStreamer modules into one single mono repository

This merge request lays out the foundations for merging all our repositories into one.

This has been discussed in the community for a long time, and I think we have a consensus about the principle of a mono repo.

We should make the goal of this discussion to elaborate a practical, explicit consensus now. This is too important a decision to not have everyone in @gstreamer on board and aware of the implications.

Pros and cons of a monorepo

Pros:

• Simplifies cross-module development, gst-build helps with that but there still exist friction points related to the current multi-repo approach
• Simplifies CI a lot
• Simplifies the build definitions a lot
• Makes it clearer what the official GStreamer modules are
• Makes it possible to have experimental internal APIs usable in all the gstreamer/ monorepo without exposing it outside GStreamer
• Makes bisecting regressions much simpler
• Avoids having to duplicate changes in each and every repo when some GLib symbols are deprecated for example, or in meson.
• Simplifies the release process as we won't need to handle 20 different modules, but 1!

Cons:

• Legal issues with ugly? How does FFmpeg handle these issues?
• Some disruption in the development and packaging process, this is a one time thing though
• The mono git repository is quite big (the .git is ~500MB)

tim_entry_point()

Technical solution

To not lose any history and have all modules as one, without breaking single commits sha, merging repositories has been done with the following pseudo code (from the GStreamer core repository):

foreach GSTREAMER_MODULE
    git remote add GSTREAMER_MODULE.name GSTREAMER_MODULE.url
    git fetch GSTREAMER_MODULE.name
    git merge GSTREAMER_MODULE.name/master
    git mv list_all_files_from_merged_gstreamer_module() GSTREAMER_MODULE.shortname
    git commit -m "Moved all files from " + GSTREAMER_MODULE.name
endforeach

The exact code used can be found here, extended from @xclaesse

This approach has the following advantages:

• checksum of each individual commit is preserved

• we can cherry-pick commits from now merged modules, allowing pending merge requests to easily be reopened against the new monorepo

• We can cherry-pick patches from the monorepo to the individual previous modules repos for stable releases doing:

  cd $GST_BUILD_PATH/gst-plugins-base
  git remote add monorepo https://gitlab.freedesktop.org/gstreamer/gstreamer.git
  git fetch monorepo
  git cherry-pick <sha from monorepo>

What does that MR implement

• Merged modules with the new directory they landed in:

  • gst-plugins-base -> base/
  • gst-plugins-good -> good/
  • gst-plugins-bad -> bad/
  • gst-plugins-ugly -> ugly/
  • gstreamer-vaapi -> vaapi/
  • gst-omx -> omx/
  • gst-libav -> ffmpeg/
  • gst-ci -> ci/
  • gst-rtsp-server -> rtsp-server/
  • gst-editing-services -> editing-services/
  • gst-devtools -> devtools/
  • gst-docs -> docs/
  • gst-examples -> examples/
  • gst-integration-testsuites -> tests/integration/
  • gst-python -> bindings/python/
  • gstreamer-sharp -> bindings/csharp/
  • gstreamer-rs -> bindings/rust/
  • gstreamer-rs-sys -> bindings/rust-sys/
  • gst-plugins-rs -> bindings/rust-plugins/
  • gst-build -> devtools/devenv/

• Integrated meson build system for all modules, with features to enable/disable components, auto features are not so well supported right now though.

• CI has been ported over, modulo cerbero

• Build products parity

What is known to be missing

• Moving more files around manually: remove some READMES, add toplevel LICENSE/ etc..
• Fix documentation
• See how we can better handle modulename=auto in meson
• Port cerbero
• Mass move issues from the different modules to the gstreamer project (should be simple to do in the UI)

Plan

If we agree with doing something like that, we should discuss the approach I am proposing here, then we will need to properly plan the move, make annoucements to the mailing list etc...

But first, let's discuss the general idea and approach here!