1 |
|
|
2 |
|
Project standards |
3 |
|
----------------- |
4 |
|
|
5 |
|
* Bug fixes and small code changes are updated in the CVS and the |
6 |
|
mailing list is notified later. |
7 |
|
|
8 |
|
* Adding new Features is the other way around. A proposal for a new |
9 |
|
Feature is first sent to the mailing list, discussed there (and |
10 |
|
possible voted on in case of major changes). If accepted, the CVS |
11 |
|
is updated with the new code. |
12 |
|
|
13 |
|
Adding new features also include updating the monit.pod file, |
14 |
|
the CHANGES.txt and other relevant documentation files, like |
15 |
|
./monitrc for configuration syntax or semantic changes. It is |
16 |
|
important that the documentation is *always* aligned with the |
17 |
|
lates codebase. |
18 |
|
|
19 |
|
* Add yourself as an author to any files you have changed |
20 |
|
substantially. Substantially changes means adding a new method |
21 |
|
or adding more than a couple of new code lines in a file so the |
22 |
|
program behavior was changed. The reason is mainly that you get |
23 |
|
the credit for the work you have done and partly that others |
24 |
|
will know whom to blame. |
25 |
|
|
26 |
|
|
27 |
|
Decision Making (Done as in the Apache Project) |
28 |
|
----------------------------------------------- |
29 |
|
|
30 |
|
* All Contributors are encouraged to participate in decisions, but |
31 |
|
the decision itself is made by those that have Committer status |
32 |
|
in the Project. In other words, the Project is a "Minimum |
33 |
|
Threshold Meritocracy". |
34 |
|
|
35 |
|
* Each vote can be made in one of three flavors: |
36 |
|
|
37 |
|
+1 "Yes," "Agree," or "the action should be performed." On some |
38 |
|
issues this is only binding if the voter has tested the |
39 |
|
action on their own system(s). |
40 |
|
|
41 |
|
0 "Abstain," "no opinion". An abstention may have detrimental |
42 |
|
effects if too many people abstain. |
43 |
|
|
44 |
|
-1 "No." On issues where consensus is required, this vote counts |
45 |
|
as a veto. All vetos must contain an explanation of why the |
46 |
|
veto is appropriate. Vetos with no explanation are void. No |
47 |
|
veto can be overruled. If you disagree with the veto, you |
48 |
|
should lobby the person who cast the veto. Voters intending |
49 |
|
to veto an action item should make their opinions known to |
50 |
|
the group immediately so that the problem can be remedied as |
51 |
|
early as possible. |
52 |
|
|
53 |
|
|
54 |
Programs you will need to build a monit package |
Programs you will need to build a monit package |
55 |
----------------------------------------------- |
----------------------------------------------- |
56 |
|
|
89 |
script to create the man files. |
script to create the man files. |
90 |
|
|
91 |
|
|
|
Project standards |
|
|
----------------- |
|
|
|
|
|
* Bug fixes and small code changes are updated in the CVS and the |
|
|
mailing list is notified later. |
|
|
|
|
|
|
|
|
* Adding new Features is the other way around. A proposal for a new |
|
|
Feature is first sent to the mailing list, discussed there (and |
|
|
possible voted on in case of major changes). If accepted, the CVS |
|
|
is updated with the new code. |
|
|
|
|
|
Adding new features also include updating the monit.pod file, |
|
|
the CHANGES.txt log and other relevant documentation files, like |
|
|
./monitrc for configuration syntax or semantic changes. It is |
|
|
important that the documentation *always* is aligned with the |
|
|
lates codebase. |
|
|
|
|
|
|
|
|
* Add yourself as an author to any files you have changed |
|
|
substantially. Substantially changes means adding a new method |
|
|
or adding more than a couple of new code lines in a file so the |
|
|
program behavior was changed. The reason is partly that you get |
|
|
the recognition for the work you have done and partly that |
|
|
others will know who to blame. |
|
|
|
|
|
|
|
92 |
CVS standards |
CVS standards |
93 |
------------- |
------------- |
94 |
|
|
110 |
|
|
111 |
|
|
112 |
For Project Managers: |
For Project Managers: |
|
|
|
113 |
|
|
114 |
* Every file in the project *must* be tagged with a release tag |
* Every file in the project *must* be tagged with a release tag |
115 |
matching the version number in monitor.h.in before a new release |
matching the version number in configure.ac before a new release |
116 |
is released. We use the following release tag standard: |
is released. We use the following release tag standard: |
117 |
release-x-y(-z) e.g. release-2-4-2 |
release-x-y(-z) e.g. release-2-4-2 |
118 |
|
|