s/GitHub/GitLab/
This commit is contained in:
Simon Ser
parent
d1b75674d4
commit
8bc1086cac
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Reference in New Issue