-
Notifications
You must be signed in to change notification settings - Fork 62
/
README.DEVELOPER
135 lines (95 loc) · 4.34 KB
/
README.DEVELOPER
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
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 and other relevant documentation files, like
./monitrc for configuration syntax or semantic changes. It is
important that the documentation is *always* 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 mainly that you get
the credit for the work you have done and partly that others
will know whom to blame.
Decision Making
---------------
* All Contributors are encouraged to participate in decisions, but
the decision itself is made by those that have Committer status
in the Project. In other words, the Project is a "Minimum
Threshold Meritocracy".
* Each vote can be made in one of three flavors:
+1 "Yes," "Agree," or "the action should be performed." On some
issues this is only binding if the voter has tested the
action on their own system(s).
0 "Abstain," "no opinion". An abstention may have detrimental
effects if too many people abstain.
-1 "No." On issues where consensus is required, this vote counts
as a veto. All vetos must contain an explanation of why the
veto is appropriate. Vetos with no explanation are void. No
veto can be overruled. If you disagree with the veto, you
should lobby the person who cast the veto. Voters intending
to veto an action item should make their opinions known to
the group immediately so that the problem can be remedied as
early as possible.
Programs you will need to build a monit package
-----------------------------------------------
* GNU make
* pod2html and pod2man
* flex
* yacc or bison (bison is recommended)
* Perl
* GNU tar and GNU gzip
* autoconf (v. >= 2.53)
* automake (v. >= 1.5)
* doxygen (v. >= 1.2.15)
Setting up the developing environment
-------------------------------------
1. Run autogen.sh to create and run configure, or alternatively do:
autoheader
autoconf
./configure
Pass any configure arguments on the command line of autogen.sh if
you are running autogen.sh.
2. You will now have a Makefile for building the program. The
Makefile will handle any additional source files you add to the
project and will link everything to monit.
3. The man file for the project is monit.pod and a monit.1 man
file is created by using perl-pod and pod2man.
4. To build a new release run the make_dist script. This will
create a monit-{release-number}.tar.gz file in the current
directory.
SVN standards
-------------
* ONLY check in files that will compile without any warnings.
(Change the CFLAGS macro in the Makefile to include -Wall;
CFLAGS = -Wall .. to compile with all warnings turned on)
* Regularly do a 'svn update' to keep your local copy in sync
with the master repository.
* To check out trunk (development):
svn checkout http://monit.googlecode.com/svn/trunk/ monit
* To check out the complete source code repository:
svn checkout http://monit.googlecode.com/svn/ monit
For Project Managers:
* Every file in the project *must* be tagged with a release tag
matching the version number in configure.ac before a new release
is released. We use the following release tag standard:
release-x-y-z e.g. release-5-0-3
* The release numbers explained:
x is for major feature releases
y is for minor feature releases
z is for bug fix releases
* To tag a new release in svn:
svn checkout http://monit.googlecode.com/svn/ svn
cd svn
svn copy trunk tags/release-x-y-z
svn ci
* Only the project manager should create and tag a new
release
--
hauk@tildeslash.com