s/GitHub/GitLab/

This commit is contained in:
Simon Ser 2021-11-01 17:28:16 +01:00
parent d1b75674d4
commit 8bc1086cac
5 changed files with 21 additions and 21 deletions

View file

@ -18,7 +18,7 @@ packages:
- xwayland
- libseat-dev
sources:
- https://github.com/swaywm/wlroots
- https://gitlab.freedesktop.org/wlroots/wlroots.git
tasks:
- setup: |
cd wlroots

View file

@ -19,7 +19,7 @@ packages:
- vulkan-headers
- glslang
sources:
- https://github.com/swaywm/wlroots
- https://gitlab.freedesktop.org/wlroots/wlroots.git
tasks:
- setup: |
cd wlroots

View file

@ -26,7 +26,7 @@ packages:
- sysutils/seatd
- gmake
sources:
- https://github.com/swaywm/wlroots
- https://gitlab.freedesktop.org/wlroots/wlroots.git
tasks:
- wlroots: |
cd wlroots

View file

@ -1,21 +1,21 @@
# Contributing to wlroots
Contributing just involves sending a pull request. You will probably be more
Contributing just involves sending a merge request. You will probably be more
successful with your contribution if you visit [#sway-devel on Libera Chat]
upfront and discuss your plans.
Note: rules are made to be broken. Adjust or ignore any/all of these as you see
fit, but be prepared to justify it to your peers.
## Pull Requests
## Merge Requests
If you already have your own pull request habits, feel free to use them. If you
If you already have your own merge request habits, feel free to use them. If you
don't, however, allow me to make a suggestion: feature branches pulled from
upstream. Try this:
1. Fork wlroots
2. `git clone git@github.com:<username>/wlroots.git && cd wlroots`
3. `git remote add upstream https://github.com/swaywm/wlroots`
2. `git clone git@gitlab.freedesktop.org:<username>/wlroots.git && cd wlroots`
3. `git remote add upstream https://gitlab.freedesktop.org/wlroots/wlroots.git`
You only need to do this once. You're never going to use your fork's master
branch. Instead, when you start working on a feature, do this:
@ -24,11 +24,11 @@ branch. Instead, when you start working on a feature, do this:
2. `git checkout -b add-so-and-so-feature upstream/master`
3. Add and commit your changes
4. `git push -u origin add-so-and-so-feature`
5. Make a pull request from your feature branch
5. Make a merge request from your feature branch
When you submit your pull request, your commit log should do most of the talking
When you submit your merge request, your commit log should do most of the talking
when it comes to describing your changes and their motivation. In addition to
this, your pull request's comments will ideally include a test plan that the
this, your merge request's comments will ideally include a test plan that the
reviewers can use to (1) demonstrate the problem on master, if applicable and
(2) verify that the problem no longer exists with your changes applied (or that
your new features work correctly). Document all of the edge cases you're aware
@ -80,15 +80,15 @@ cmd_move"* or *"Improve performance of arrange_windows on ARM"* or similar.
The subsequent lines should be separated from the subject line by a single
blank line, and include optional details. In this you can give justification
for the change, [reference Github issues], or explain some of the subtler
for the change, [reference issues], or explain some of the subtler
details of your patch. This is important because when someone finds a line of
code they don't understand later, they can use the `git blame` command to find
out what the author was thinking when they wrote it. It's also easier to review
your pull requests if they're separated into logical commits that have good
your merge requests if they're separated into logical commits that have good
commit messages and justify themselves in the extended commit description.
As a good rule of thumb, anything you might put into the pull request
description on Github is probably fair game for going into the extended commit
As a good rule of thumb, anything you might put into the merge request
description on GitLab is probably fair game for going into the extended commit
message as well.
See [How to Write a Git Commit Message] for more details.
@ -101,16 +101,16 @@ changes will typically see review from several people. Be prepared to receive
some feedback - you may be asked to make changes to your work. Our code review
process is:
1. **Triage** the pull request. Do the commit messages make sense? Is a test
1. **Triage** the merge request. Do the commit messages make sense? Is a test
plan necessary and/or present? Add anyone as reviewers that you think should
be there (using the relevant GitHub feature, if you have the permissions, or
be there (using the relevant GitLab feature, if you have the permissions, or
with an @mention if necessary).
2. **Review** the code. Look for code style violations, naming convention
violations, buffer overflows, memory leaks, logic errors, non-portable code
(including GNU-isms), etc. For significant changes to the public API, loop in
a couple more people for discussion.
3. **Execute** the test plan, if present.
4. **Merge** the pull request when all reviewers approve.
4. **Merge** the merge request when all reviewers approve.
5. **File** follow-up tickets if appropriate.
## Style Reference
@ -396,6 +396,6 @@ static void subsurface_handle_surface_destroy(struct wl_listener *listener,
[#sway-devel on Libera Chat]: https://web.libera.chat/gamja/?channels=#sway-devel
[linear, "recipe" style]: https://www.bitsnbites.eu/git-history-work-log-vs-recipe/
[git-rebase.io]: https://git-rebase.io/
[reference Github issues]: https://help.github.com/articles/closing-issues-via-commit-messages/
[reference issues]: https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically
[How to Write a Git Commit Message]: https://chris.beams.io/posts/git-commit/
[kernel style]: https://www.kernel.org/doc/Documentation/process/coding-style.rst

View file

@ -75,9 +75,9 @@ Install like so:
See [CONTRIBUTING.md].
[Wayland]: https://wayland.freedesktop.org/
[wiki]: https://github.com/swaywm/wlroots/wiki/Getting-started
[wiki]: https://gitlab.freedesktop.org/wlroots/wlroots/-/wikis/Getting-started
[#sway-devel on Libera Chat]: https://web.libera.chat/gamja/?channels=#sway-devel
[Sway]: https://github.com/swaywm/sway
[wrapper libraries]: https://github.com/search?q=topic%3Abindings+org%3Aswaywm&type=Repositories
[libseat]: https://git.sr.ht/~kennylevinsen/seatd
[CONTRIBUTING.md]: https://github.com/swaywm/wlroots/blob/master/CONTRIBUTING.md
[CONTRIBUTING.md]: https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/master/CONTRIBUTING.md