/[monit]/monit/README.DEVELOPER
ViewVC logotype

Diff of /monit/README.DEVELOPER

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.7 by rory, Tue Aug 27 02:49:51 2002 UTC revision 1.8 by hauk, Thu Sep 5 21:24:37 2002 UTC
# Line 1  Line 1 
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    
# Line 37  Setting up the developing environment Line 89  Setting up the developing environment
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    
# Line 85  CVS standards Line 110  CVS standards
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    

Legend:
Removed from v.1.7  
changed lines
  Added in v.1.8

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26