File: contrib-guidelines.html

package info (click to toggle)
mon-contrib 1.0%2Bdfsg-5
  • links: PTS, VCS
  • area: main
  • in suites: forky, sid, trixie
  • size: 892 kB
  • sloc: perl: 5,510; sh: 383; python: 118; makefile: 72
file content (72 lines) | stat: -rw-r--r-- 2,404 bytes parent folder | download | duplicates (5)
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
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html> <head>
<title>mon /contrib -- guidelines</title>
</head>

<body>
<h1>mon /contrib -- guidelines</h1>
<hr>

<p>We encourage mon users to submit their own monitors, graphical
front-ends, patches, and other utilities back into the mon
community. These utilities are collected here.
</p>

<p>This page describes the procedure for getting your contributions in
the /contrib tree. We want to encourage submissions, but at the same
time, we would like to keep the quality reasonable and have everything
reasonably well-documented.
</p>

<p>If you are submitting new material to the /contrib tree, you must
include the following with each submission:
<ol>
  <li>A brief (one paragraph) description of what your
       submission does.
  </li>
  <li>A file containing your submission. If there is only one
       file (e.g. a self-documented monitor script), then send
       that. If there are multiple files in your distribution,
       these must be sent in a compressed tar (.tar.gz) archive.
  </li>
  <li>A README file, describing in more detail what your
       submission does, how to install it, who might find it
       useful,
       etc. See sample README files in the /contrib tree for examples
       of what is needed. In general, the better your README file, the
       more chance 
       other people will use your software.
  </li>
</ol>
</p>

<p>If you are submitting a patch to another contrib'ed item, please
note the following:
<ol>
  <li>Your patch should fix a bug, or add a new piece of functionality,
       preferably by being backwards compatible. If you need or want to
       significantly change the way a monitor works, you might
       consider making a new monitor.        
  </li>
  <li>Send patches as attached context diffs, noting what is fixed and
       how.
  </li>
  <li>There is absolutely no rule that
       limits the number of monitors for a particular service, for
       example, just because there are already 5 different HTTP
       monitors doesn't mean another one isn't necessary or useful.
  </li>
</ol>
</p>

<p>Send your submissions via email to <a
href="mailto:trockij@linux.kernel.org">trockij@linux.kernel.org</a>.
</p>

<p>Submissions not meeting these guidelines may not be accepted.
</p>


<hr>
<!-- hhmts start --> Last modified: Tue May 22 21:47:42 PDT 2001 <!-- hhmts end -->
</body> </html>