[RFC] GStreamer git repositories unification

[Thibault Saunier]

Hi everyone,

GStreamer's developer community has been discussing the unification of our
many
git repositories for a while [on gitlab]. We have come up with [a first
version]
and it is probably time for everyone using GStreamer to give it a spin and
some
feedback.

[on gitlab]: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/474
[a first version]:
https://gitlab.freedesktop.org/thiblahute/gstreamer/-/tree/monorepo_simple

## What is it?

Merges all GStreamer modules into a single git repository:

* gstreamer (core)
* gst-plugins-base
* gst-plugins-good
* gst-plugins-bad
* gst-plugins-ugly
* gstreamer-vaapi
* gst-omx
* gst-libav
* gst-ci
* gst-rtsp-server
* gst-editing-services
* gst-devtools
* gst-docs
* gst-examples
* gst-integration-testsuites
* gst-python
* gstreamer-sharp
* gstreamer-rs
* gst-plugins-rs
* gst-build

The full git history of all those modules is merged into the existing
`gstreamer` git repo, every commit hash is preserved. The initial intention
is
only to merge the git repositories and keep producing separate release
tarballs.
Each GStreamer component can still be built on its own.

Note that only current master branches are being unified, stable branches
will
remain in their own repositories.

## Why?

- Cross-repository changes are currently painful because multiple merge
requests
  need to be managed in various repositories. It is easier for developers
and
  reviewers to have all the code in a single MR.
- Simplification of the CI infrastructure. No more manifest specifying which
  branches in which user forks need to be pulled together. The CI can
checkout
  and test a single branch. This also makes replicating a similar setup
  downstream much simpler.
- Makes bisecting regressions much simpler. Once the unification point will
be
  behind us, bisecting GStreamer will be a simple matter of running `git
bisect`
  without worrying about keeping multiple repositories in sync at each step.
- Simplifies the release process as it can be prepared in a single MR
instead of
  bumping version and tagging each module separately.
- Makes easier to move files across modules, such as moving plugins from
-bad to
  -good or -ugly.
- Removes the need for a bug reporter to figure out against what repository
the
  bug should be filed.

An extensive list of pros and cons can be found here:
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/474#pros-and-cons-of-a-monorepo

## What does it mean for distributions?

Since release tarballs are preserved, nothing should change for packagers.

## What does it mean for contributors?

- The unified gstreamer repository will have the same layout as gst-build.
- All merge requests targeting master branch will have to be made against
the
  main gstreamer repository.
- Existing merge requests on other repositories (e.g. gst-plugins-good) will
  have to be resubmitted on the main repo. A simple cherry-pick usually
  works.
- All GitLab issues will be moved to the main repository.

We have prepared a [checklist] so you can see how we currently think about
making it happen. This is a Request For Comment for the broader community to
help us execute it as well as possible, so that initial plan may change.

[checklist]:
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/474#plan

Best regards,

-- 
Thibault Saunier, Igalia - www.igalia.com <http://www.centricular.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20201125/ab272c3b/attachment.htm>