Switch branches/tags
Nothing to show
Find file
Fetching contributors…
Cannot retrieve contributors at this time
136 lines (95 sloc) 4.34 KB
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 to create and run configure, or alternatively do:
Pass any configure arguments on the command line of if
you are running
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
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 monit
* To check out the complete source code repository:
svn checkout monit
For Project Managers:
* Every file in the project *must* be tagged with a release tag
matching the version number in 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 svn
cd svn
svn copy trunk tags/release-x-y-z
svn ci
* Only the project manager should create and tag a new