blob: 67fe4705976e4f52d09220be48e1f37a6bae6e91 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
|
This document describes how maintainership works on GNOME Settings. It is intended to be a guideline
for future reference.
The list of current maintainers can be found at the [gnome-control-center.doap][doap] DOAP file.
# General Rules
The purpose of the shared maintainership model in GNOME Settings is to avoid as much as possible
pushing unreviewed code in the main repository. Not only it is a good engineering practice, but it
also increases the code quality and reduces the number of bugs.
GNOME Settings has two types of maintainers:
* **General Maintainer**: take care of the whole codebase and of panels without a specific maintainer.
* **Panel Maintainer**: take care of a specific panel with a stronger authority over General
Maintainers.
## For Contributors
Panel Maintainers have a stronger authority over their panels than a General Maintainer. If you are
contributing to a specific panel, and that panel has a dedicate maintainer, they should be the main
point of contact.
In the rare case of Panel Maintainers not being responsive, it is allowed to contact General
Maintainers.
## For Maintainers
If you are a Panel Maintainer, your merge requests will be reviewed by General Maintainer. The
opposite is true as well - General Maintainers contributing to a specific panel will have their
merge requests reviewed by the Panel Maintainer of that panel.
If you are a General Maintainer contributing to an unmaintained panel, or to the main codebase, your
merge requests will be reviewed by another General Maintainer.
Avoid pushing commits without an explicit review, except in the following cases:
* The commit is a translation commit
* The commit is trivial
* The commit is urgent and no reviewers were available in time
When accepting a merge request and allowing the other maintainer to merge, avoid misunderstandings
by being explicit. Suggested acceptance phrase:
`I approve this merge request. You are allowed to merge it.`
### Urgency Commits
Urgency commits should never happen, but in case they're needed, they are defined by the following
criteria:
* On stable branches (or `main` right after a stable release)
* Symptoms:
* Always OR often reproducible; AND
* Crash; OR
* Data loss; OR
* System corruption
* Quickly followed by an emergency release (at most 2 days after the commit)
[doap]: https://gitlab.gnome.org/GNOME/gnome-control-center/blob/main/gnome-control-center.doap
|
