From 2d4ead6f2fb3d288cf3a3897765d69e6602140b0 Mon Sep 17 00:00:00 2001 From: Simon McVittie Date: Wed, 3 Oct 2018 16:27:59 +0100 Subject: CONTRIBUTING: Rewrite This resembles a similar change in dbus-glib. Much of the text here was taken from Wayland's contributing guide (thanks to Ander Conselvan de Oliveira, Bryce Harrington, Eric Engestrom, Pekka Paalanen and Daniel Stone). Signed-off-by: Simon McVittie --- CONTRIBUTING | 109 ++++++++++++++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 97 insertions(+), 12 deletions(-) diff --git a/CONTRIBUTING b/CONTRIBUTING index 99916fe..5bbcee1 100644 --- a/CONTRIBUTING +++ b/CONTRIBUTING @@ -1,25 +1,110 @@ -The mainline git tree for this code is at: -git://anongit.freedesktop.org/git/dbus/dbus-glib -b dbus-gmain +# Contributing to dbus-gmain -= Contributing changes = +dbus-gmain is hosted by freedesktop.org. The source code repository, +issue tracking and merge requests are provided by freedesktop.org's +Gitlab installation, as a branch in the dbus-glib project: + -Be sure to match the existing code style (Emacs: "gnu"). +## Making changes -If you are making major changes which you wish to be incorporated upstream, -please do as small commits to your local git tree, so there is a good -history of your changes. +If you are making changes that you wish to be incorporated upstream, +please do as small commits to your local git tree that are individually +correct, so there is a good history of your changes. -When you consider changes ready for merging to mainline, use -"git-format-patch" or otherwise generate unified diffs. Post those diffs -to a new bug at http://bugs.freedesktop.org, project DBus, component GLib. +The first line of the commit message should be a single sentence that +describes the change, optionally with a prefix that identifies the +area of the code that is affected. + +The body of the commit message should describe what the patch changes +and why, and also note any particular side effects. This shouldn't be +empty on most of the cases. It shouldn't take a lot of effort to write a +commit message for an obvious change, so an empty commit message body is +only acceptable if the questions "What?" and "Why?" are already answered +on the one-line summary. + +The lines of the commit message should have at most 76 characters, +to cope with the way git log presents them. + +See [notes on commit messages](https://who-t.blogspot.com/2009/12/on-commit-messages.html), +[A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html) +or [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/) +for recommended reading on writing high-quality commit messages. + +Your patches should also include a Signed-off-by line with your name and +email address, indicating that your contribution follows the [Developer's +Certificate of Origin](https://developercertificate.org/). If you're +not the patch's original author, you should also gather S-o-b's by +them (and/or whomever gave the patch to you.) The significance of this +is that it certifies that you created the patch, that it was created +under an appropriate open source license, or provided to you under those +terms. This lets us indicate a chain of responsibility for the copyright +status of the code. + +We won't reject patches that lack S-o-b, but it is strongly recommended. + +When you consider changes ready for merging to mainline: + +* create a personal fork of + on freedesktop.org Gitlab +* push your changes to your personal fork as a branch +* create a merge request at + , + and remember to specify `dbus-gmain` as the target branch + +## Automated tests For nontrivial changes please try to extend the test suite to cover it. +dbus-gmain uses GLib's test framework; tests are in the `tests/` +directory. + +Run `make check` to run the test suite. + +## Coding style + +Please match the existing code style (Emacs: "gnu"). + +## Licensing -Run "make check" to run the test suite. +Please match the existing licensing (a dual-license: AFL-2.1 or GPL-2+, +recipient's choice). Entirely new modules can be placed under a more +permissive license: to avoid license proliferation, our preferred +permissive license is the variant of the MIT/X11 license used by the +Expat XML library (for example see the top of tools/ci-build.sh). -= Releases = +## Conduct + +As a freedesktop.org project, dbus follows the Contributor Covenant, +found at: + +Please conduct yourself in a respectful and civilised manner when +interacting with community members on mailing lists, IRC, or bug +trackers. The community represents the project as a whole, and abusive +or bullying behaviour is not tolerated by the project. + +## (Lack of) versioning and releases dbus-gmain is currently set up to be a git subtree or git submodule, so it does not have releases in its own right. It gets merged or otherwise included in larger projects like dbus-glib and dbus-python instead. + +## Information for maintainers + +This section is not directly relevant to infrequent contributors. + +### Updating the copies of dbus-gmain in dbus-glib and dbus-python + +dbus-gmain is maintained via `git subtree`. To update one of the dependent +projects, assuming you have a checkout of the dbus-gmain branch of the +dbus-glib repository in ../dbus-gmain: + + git subtree pull -P dbus-gmain ../dbus-gmain HEAD + +### Committing other people's patches + +If applying a patch from someone else that created them via +"git-format-patch", you can use "git-am -s" to apply. Otherwise +apply the patch and then use "git commit --author ..." + +Nontrivial patches should always go through Gitlab for peer review, +so you should have an issue number or a merge request ID to refer to. -- cgit v1.2.1