<div dir="ltr">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]: <a href="https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/474">https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/474</a> [a first version]: <a href="https://gitlab.freedesktop.org/thiblahute/gstreamer/-/tree/monorepo_simple">https://gitlab.freedesktop.org/thiblahute/gstreamer/-/tree/monorepo_simple</a> ## 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: <a href="https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/474#pros-and-cons-of-a-monorepo">https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/474#pros-and-cons-of-a-monorepo</a> ## 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. <div>[checklist]: <a href="https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/474#plan">https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/474#plan</a></div><div> </div><div>Best regards, </div> -- <div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Thibault Saunier, Igalia - <a href="http://www.igalia.com" target="_blank">www.igalia.com</a><a href="http://www.centricular.com" rel="noreferrer" target="_blank"></a></div></div></div>