From 22671ebc350aa4af3e23261c5033e062571a84c4 Mon Sep 17 00:00:00 2001 From: Lars Wirzenius Date: Sat, 2 Nov 2019 10:07:40 +0200 Subject: Change: point to gitlab, clean up contribution advice --- patches.mdwn | 20 ++++++++------------ 1 file changed, 8 insertions(+), 12 deletions(-) diff --git a/patches.mdwn b/patches.mdwn index 4f5b035..2865c6c 100644 --- a/patches.mdwn +++ b/patches.mdwn @@ -5,6 +5,7 @@ page explains how you can contribute changes to either. [git]: https://git-scm.com/ [git.liw.fi]: http://git.liw.fi/ +[gitlab]: https://gitlab.com/larswirzenius/vmdb2 [vmdb2]: http://git.liw.fi/vmdb2/ [vmdb2.liw.fi]: http://git.liw.fi/vmdb2.liw.fi [Gitano]: https://www.gitano.org.uk/ @@ -15,16 +16,11 @@ on a [git.liw.fi][], a personal server hosted by Lars Wirzenius, using the [Gitano][] software. See the [vmdb2][] and [vmdb2.liw.fi][] repositories. -We don't use GitHub, as it runs proprietary -software, and [free software should use free tools][]. We also don't -use one of the free software implementations that are similar to -GitHub, because we prefer Gitano, and some of us don't enjoy the -pull-request style of accepting contributions that GitHub has. -However, we're happy to get changes from GitHub, or any other git -server, over an open protocol. +An identical repository is hosted on [gitlab][] for those who prefer +the merge-request based workflow. GitLab is not entire free software, +but "open core", and [free software should use free tools][]. -Despite our aversion toward GitHub and pull requests, we want to make -it easy for you to send us patches. +We want to make it easy for you to send us patches. Here's a few ways you can send us changes: @@ -45,16 +41,16 @@ Here's a few ways you can send us changes: * Make the changes available on a different git server, and send us a URL we can pull from. You can use GitHub or any other server that's convenient for you. You can even create a pull request and send a - URL to that. + link to that. -# On patches (and pull requests) +# On patches (and pull requests and merge requests) We prefer a patch series and pull request to tell a story of the change that is easy to follow and review and understand. * Each patch/commit should have a clear commit message. The commit - message should explain why the change is made, and not just repharse + message should explain why the change is made, and not just rephrase the diff. The commit message should stand on its own, as it will be read on its own in the future, when someone is debugging the program, possibly with "git bisect". -- cgit v1.2.1