docs: contribute: update how-to-submit-patches section for monorepo

See https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/840#note_1114907

Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1231>
This commit is contained in:
Tim-Philipp Müller 2021-10-22 17:56:26 +01:00 committed by GStreamer Marge Bot
parent 22f502d864
commit 77a415c460

View file

@ -115,6 +115,12 @@ that it is accessible and working.
If you have not done so already, you may need to first If you have not done so already, you may need to first
[set up SSH keys in your GitLab User Settings](https://gitlab.freedesktop.org/profile/keys). [set up SSH keys in your GitLab User Settings](https://gitlab.freedesktop.org/profile/keys).
**Once you have done that, please make your repository public.** By default
newly-forked repositories might be private, but that causes problems for
maintainers and merge bots, so please go to the newly-created repository's
settings (https://gitlab.freedesktop.org/$USERNAME/gstreamer/edit) and set
the visibility to public. Thanks!
Next, you make a git branch with one or more commits you want to submit Next, you make a git branch with one or more commits you want to submit
for review and merging. For that you will first need a local branch which for review and merging. For that you will first need a local branch which
you can create with e.g. you can create with e.g.
@ -149,10 +155,12 @@ Couple of additional points:
- You do not have to file an issue to go with each Merge Request, it's fine - You do not have to file an issue to go with each Merge Request, it's fine
to just submit a Merge Request on its own. to just submit a Merge Request on its own.
- **Please enable the "Allow commits from members who can merge to the target branch"** - **Please make sure the "Allow commits from members who can merge to the target branch"**
**checkbox when submitting merge requests** as otherwise maintainers can't **checkbox is enabled when submitting merge requests** as otherwise
rebase your Merge Request when they want to merge it, which means they maintainers (and our merge bot) can't rebase your Merge Request when they
won't be able to merge it. want to merge it, which means they won't be able to merge it. If you can't
enable the check box that means your personal repository fork is private.
In that case, please go to the settings and change visibility to public.
- If your proposed changes are proposed for review but not ready to be merged - If your proposed changes are proposed for review but not ready to be merged
yet, please prefix the Merge Request title with `WIP:` for Work-in-Progress. yet, please prefix the Merge Request title with `WIP:` for Work-in-Progress.
@ -222,14 +230,15 @@ Couple of additional points:
### How to Prepare a Merge Request for Submission ### How to Prepare a Merge Request for Submission
Please prepare any merge request against a current git checkout, ideally against Please prepare any merge request against a current git checkout of the
the tip of the master branch. If a merge request is prepared against an old GStreamer monorepo (gstreamer module), against the tip of the `main` branch.
commit or older branch and can't easily be rebased you may be asked to rebase If a merge request is prepared against an old commit or older branch and can't
and update the branch on top of the master branch. be easily rebased you may be asked to rebase and update the branch on top of
the `main` branch.
If you have created a new plugin, please submit a merge request that adds it to If you have created a new plugin, please submit a merge request that adds it to
the gst-plugins-bad module, including `meson.build` modifications, new files `subprojects/gst-plugins-bad`, including any required `meson.build` modifications,
and documentation. new files and documentation.
#### Preparation: create a personal fork of the git repository on GitLab #### Preparation: create a personal fork of the git repository on GitLab
@ -240,8 +249,23 @@ the module in question (e.g. <https://gitlab.freedesktop.org/gstreamer/gstreamer
and hit the fork button. A new repository will be created in your user namespace and hit the fork button. A new repository will be created in your user namespace
and should be accessible as and should be accessible as
<https://gitlab.freedesktop.org/$USERNAME/gstreamer>. <https://gitlab.freedesktop.org/$USERNAME/gstreamer>.
You should clone this repository with valid ssh credentials to be able to
automatically push code to your fork. Clone the main gstreamer repository, like this:
git clone https://gitlab.freedesktop.org/gstreamer/gstreamer.git
and then add your personal fork as a git remote like this:
git remote add my-personal-gitlab-fork git@gitlab.freedesktop.org:$USERNAME/gstreamer.git
Check with
git fetch my-personal-gitlab-fork
that it is accessible and working.
If you have not done so already, you may need to first
[set up SSH keys in your GitLab User Settings](https://gitlab.freedesktop.org/profile/keys).
#### Creating a branch for the merge request and adding commits to it #### Creating a branch for the merge request and adding commits to it
@ -372,10 +396,13 @@ The important part is really what the reasoning behind the change is, since
that's what people want to know if they try to figure out twelve months later that's what people want to know if they try to figure out twelve months later
why a line of code does what it does. why a line of code does what it does.
If the commit is related to any particular issues in gitlab, please add the If the commit is related to any particular issues in gitlab, please add a
full issue URL at the end of the commit message. reference to the issue (e.g. `See #123` or `Fixes #123` if it fixes it the
issue). For issues in other repositories (gst-plugins-{base,good,ugly,bad} etc.)
please add the full issue URL to the commit message instead (or ask for the
issue to be moved to the monorepo gstreamer repository), e.g.
https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/123 https://gitlab.freedesktop.org/gstreamer/gst-plugins-foo/issues/123
We do not use `Signed-off by:` lines in GStreamer, please create commits We do not use `Signed-off by:` lines in GStreamer, please create commits
without such lines. without such lines.
@ -452,15 +479,15 @@ may not receive e-mail notifications when you update the commits in your branch.
## Backporting to a stable branch ## Backporting to a stable branch
Before backporting any changes to a stable branch, they should first be Before backporting any changes to a stable branch, they should first be
applied to the `master` branch, and should obviously not have caused any known applied to the `main` branch, and should obviously not have caused any known
outstanding regressions. The only exception here are changes that do not apply outstanding regressions. The only exception here are changes that do not apply
to the `master` branch anymore. to the `main` branch anymore.
You do not need to create backport merge requests against stable branches. You do not need to create backport merge requests against stable branches.
Backport merge requests for stable branches will be created automatically Backport merge requests for stable branches will be created automatically
based on labels on `master` branch merge requests. based on labels on `main` branch merge requests.
Existing merge request against the `master` branch, including merged ones, Existing merge request against the `main` branch, including merged ones,
that should be considered for backporting in the future should be labeled with that should be considered for backporting in the future should be labeled with
the `Needs backport` label and the label for the target stable branch the `Needs backport` label and the label for the target stable branch
(e.g. `1.18`). All merge requests with the [`Needs backport`][needs-backport] (e.g. `1.18`). All merge requests with the [`Needs backport`][needs-backport]