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
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
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
|
## Introduction
Dear maintainer. Thank you for investing the time and energy to help
make CRIU as useful as possible. Maintaining a project is difficult,
sometimes unrewarding work. Sure, you will contribute cool features
to the project, but most of your time will be spent reviewing patches,
cleaning things up, documenting, answering questions, justifying design
decisions - while everyone else will just have fun! But remember -- the
quality of the maintainers work is what distinguishes the good projects
from the great. So please be proud of your work, even the unglamorous
parts, and encourage a culture of appreciation and respect for *every*
aspect of improving the project -- not just the hot new features.
Being a maintainer is a time consuming commitment and should not be
taken lightly. This document is a manual for maintainers old and new.
It explains what is expected of maintainers, how they should work, and
what tools are available to them.
This is a living document - if you see something out of date or missing,
speak up!
## What are a maintainer's responsibility?
Part of a healthy project is to have active maintainers to support the
community in contributions and perform tasks to keep the project running.
It is every maintainer's responsibility to:
* Keep the community a friendly place
* Deliver prompt feedback and decisions on pull requests and mailing
list threads
* Encourage other members to help each other, especially in cases the
maintainer is overloaded or feels the lack of needed expertise
* Make sure the changes made respects the philosophy, design and
roadmap of the project
## How are decisions made?
CRIU is an open-source project with an open design philosophy. This
means that the repository is the source of truth for EVERY aspect of the
project. *If it's part of the project, it's in the repo. It's in the
repo, it's part of the project.*
All decisions affecting CRIU, big and small, follow the same 3 steps:
* Submit a change. Anyone can do this
* Discuss it. Anyone can and is encouraged to do this
* Accept or decline it. Only maintainers do this
*I'm a maintainer, should I make pull requests / send patches too?*
Yes. Nobody should ever push to the repository directly. All changes
should be made through submitting (and accepting) the change.
### Two-steps decision making ###
Since CRIU is extremely complex piece of software we try double hard
not to make mistakes, that would be hard to fix in the future. In order
to facilitate this, the "final" decision is made in two stages:
* We definitely want to try something out
* We think that the attempt was successful
Respectively, new features get accepted first into the *criu-dev* branch and
after they have been validated they are merged into the *master* branch. Yet,
urgent bug fixes may land directly in the master branch. If a change in
the criu-dev branch is considered to be bad (whatever it means), then it
can be reverted without propagation to the master branch. Reverting from
the master branch is expected not to happen at all, but if such an
extraordinary case occurs, the impact of this step, especially the question
of backward compatibility, should be considered in the most careful manner.
## Who decides what?
All decisions can be expressed as changes to the repository (either in the
form of pull requests, or patches sent to the mailing list), and maintainers
make decisions by merging or rejecting them. Review and approval or
disagreement can be done by anyone and is denoted by adding a respective
comment in the pull request. However, merging the change into either branch
only happens after approvals from maintainers.
In order for a patch to be merged into the criu-dev branch at least two
maintainers should accept it. In order for a patch to be merged into the
master branch the majority of maintainers should decide that (then prepare
a pull request, submit it, etc.).
Overall the maintainer system works because of mutual respect across the
maintainers of the project. The maintainers trust one another to make
decisions in the best interests of the project. Sometimes maintainers
can disagree and this is part of a healthy project to represent the point
of views of various people. In the case where maintainers cannot find
agreement on a specific change the role of a Chief Maintainer comes into
play.
### Chief maintainer
The chief maintainer for the project is responsible for overall architecture
of the project to maintain conceptual integrity. Large decisions and
architecture changes should be reviewed by the chief maintainer.
Also the chief maintainer has the veto power on any change submitted
to any branch. Naturally, a change in the criu-dev branch can be reverted
after a chief maintainer veto, a change in the master branch must be
carefully reviewed by the chief maintainer and vetoed in advance.
### How are maintainers added (and removed)?
The best maintainers have a vested interest in the project. Maintainers
are first and foremost contributors that have shown they are committed to
the long term success of the project. Contributors wanting to become
maintainers are expected to be deeply involved in contributing code,
patches review, and paying needed attention to the issues in the project.
Just contributing does not make you a maintainer, it is about building trust
with the current maintainers of the project and being a person that they can
rely on and trust to make decisions in the best interest of the project.
When a contributor wants to become a maintainer or nominate someone as a
maintainer, one can submit a "nomination", which technically is the
respective modification to the `MAINTAINERS` file. When a maintainer feels
they is unable to perform the required duties, or someone else wants to draw
the community attention to this fact, one can submit a "(self-)removing"
change.
The final vote to add or to remove a maintainer is to be approved by the
majority of current maintainers (with the chief maintainer having veto power
on that too).
One might have noticed, that the chief maintainer (re-)assignment is not
regulated by this document. That's true :) However, this can be done. If
the community decides that the chief maintainer needs to be changed the
respective "decision making rules" are to be prepared, submitted and
accepted into this file first.
Good luck!
|
