6.25 KB
Newer Older
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
= Contributing to Wayland =

== Sending patches ==

Patches should be sent to, using
git send-email. See git's documentation for help [1].

The first line of a commit message should contain a prefix indicating
what part is affected by the patch followed by one sentence that
describes the change. For examples:

    protocol: Support scaled outputs and surfaces


    doc: generate server documentation from XML too

If in doubt what prefix to use, look at other commits that change the
same file(s) as the patch being sent.

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
Eric Engestrom's avatar
Eric Engestrom committed
body is only acceptable if the questions "What?" and "Why?" are already
26 27 28 29 30
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.

Eric Engestrom's avatar
Eric Engestrom committed
See [2] for a recommended reading on writing commit messages.

33 34 35 36 37 38 39 40 41
Your patches should also include a Signed-off-by line with your name and
email address.  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.
42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116

== Tracking patches and following up ==

Patchwork is used for tracking patches to Wayland and Weston:

Xwayland patches are tracked with the Xorg project, not here.

Libinput patches, even though they use the same mailing list as Wayland, are
not tracked in the Wayland Patchwork.

The following applies only to Wayland and Weston.

If a patch is not found in Patchwork, there is a high possibility for it to be
forgotten. Patches attached to bug reports or not arriving to the mailing list
because of e.g. subscription issues will not be in Patchwork because Patchwork
only collects patches sent to the list.

When you send a revised version of a patch, it would be very nice to mark your
old patch as superseded (or rejected, if that is applicable). You can change
the status of your own patches by registering to Patchwork - ownership is
identified by email address you use to register. Updating your patch status
appropriately will help maintainer work.

The following patch states are found in Patchwork:

	Patches under discussion or not yet processed.

  Under review
	Mostly unused state.

	The patch is merged in the master branch upstream, as is or slightly

	The idea or approach is rejected and cannot be fixed by revising
	the patch.

	Request for comments, not meant to be merged as is.

  Not applicable
	The email was not actually a patch, or the patch is not for Wayland or
	Weston. Libinput patches are usually automatically ignored by Wayland
	Patchwork, but if they get through, they will be marked as Not

  Changes requested
	Reviewers determined that changes to the patch are needed. The
	submitter is expected to send a revised version. (You should
	not wait for your patch to be set to this state before revising,

  Awaiting upstream
	Mostly unused as the patch is waiting for upstream actions but
	is not shown in the default list, which means it is easy to

	A revised version of the patch has been submitted.

	Used mostly during freeze periods before releases, to temporarily
	hide patches that cannot be merged during a freeze.

Note, that in the default listing, only patches in New or Under review are

There is also a command line interface to Patchwork called 'pwclient', see
for links where to get it and the sample .pwclientrc for Wayland/Weston.

117 118 119 120 121 122 123 124
== Coding style ==

You should follow the style of the file you're editing. In general, we
try to follow the rules below.

- indent with tabs, and a tab is always 8 characters wide
- opening braces are on the same line as the if statement;
- no braces in an if-body with just one statement;
Eric Engestrom's avatar
Eric Engestrom committed
- if one of the branches of an if-else condition has braces, then the
126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149
  other branch should also have braces;
- there is always an empty line between variable declarations and the

static int
	int a = 0;

	if (a)

	if (a) {
	} else {

- lines should be less than 80 characters wide;
- when breaking lines with functions calls, the parameters are aligned
Eric Engestrom's avatar
Eric Engestrom committed
  with the opening parentheses;
151 152 153 154 155 156 157 158 159 160 161
- when assigning a variable with the result of a function call, if the
  line would be longer we break it around the equal '=' sign if it makes

	long_variable_name =
		function_with_a_really_long_name(parameter1, parameter2,
						 parameter3, parameter4);

	x = function_with_a_really_long_name(parameter1, parameter2,
					     parameter3, parameter4);

162 163 164 165 166 167 168 169 170 171 172 173 174

== Conduct ==

As a project, Wayland 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.

175 176 177 178 179 180 181
== Licensing ==

Wayland is licensed with the intention to be usable anywhere is.
Originally, was covered under the MIT X11 license, but changed to
the MIT Expat license.  Similarly, Wayland was covered initially as MIT
X11 licensed, but changed to the MIT Expat license, following in's
footsteps.  Other than wording, the two licenses are substantially the
Eric Engestrom's avatar
Eric Engestrom committed
same, with the exception of a no-advertising clause in X11 not included
183 184 185 186 187
in Expat.

New source code files should specify the MIT Expat license in their
boilerplate, as part of the copyright statement.

188 189 190 191 192 193
== References ==