[ << Working with source code ] | [Top][Contents] | [ Compiling >> ] |
[ < Lifecycle of a merge request ] | [ Up : Lifecycle of a merge request ] | [ Automated and manual testing > ] |
3.3.1 Uploading a patch for review
Any non-trivial change should be reviewed as a merge request:
https://gitlab.com/lilypond/lilypond/-/merge_requests
Ensure your branch differs from latest master
by just the changes
to be uploaded.
Make sure that make
, make test
and make doc
succeed.
Even if the individual commits contain incomplete features, they must
all pass these tests.
Branches pushed on the main repository should start with dev/
.
After pushing, create a merge request to start the review cycle. There are multiple options for this as outlined in GitLab’s documentation. This will also ask you for a message that will accompany your patch.
If you are not a member of the team and create the merge request from a fork, consider enabling the box to “Allow commits from members who can merge to the target branch”. This makes it possible for somebody with permissions to rebase your changes and merge them for you. Please refer to Merging to master for more details.
[ << Working with source code ] | [Top][Contents] | [ Compiling >> ] |
[ < Lifecycle of a merge request ] | [ Up : Lifecycle of a merge request ] | [ Automated and manual testing > ] |