-
Notifications
You must be signed in to change notification settings - Fork 42
/
PATCHES
119 lines (89 loc) · 5.64 KB
/
PATCHES
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
We know our rules place a burden on you, but rest assured that maintaining a
big and complex software project is even harder, so please accept our rules.
We cannot afford to spend our time fixing buggy, broken or outdated patches.
The closer you follow our rules the higher is the probability that your patch
will be included in our distribution.
When sending us patches, please follow the rules below :
1. Accept the license.
The OpenBricks code is licensed under GPL and most of its components are
licensed the same way (some others might be LPGL or BSD). From the moment
you send a patch, you'll have to accept the original license of the file
you're modifying. You have no right to change the distribution license
by yourself.
2. Do not send complete files.
These need to be diffed by hand to see the changes, which makes reviews
harder and less likely to occur. Besides as soon as one of the files
changes, your version becomes harder to apply, thus reducing its chances
of being accepted.
3. Always make patches against the development version.
When doing a patch, please always do it against one of the development
branches (ideally OpenBricks mercurial branch). Check on the website's
'Download' section howto to grab the latest version of our sources
from the Mercurial repository. Please never start working from an
officially released tree as it is _ALWAYS_ outdated.
4. Make unified diffs ('diff -Naur' or 'hg diff').
Unified diffs can be applied easily with 'patch'. This is much harder
with other diff types. Create the diff from the root of the OpenBricks
source tree, this makes the diff easier to apply as it saves the step of
changing to the correct directory.
5. Test the functionality of your patch.
We'll *refuse* it if it breaks something or implies regression,
even if it extends other features!
6. Do _NOT_ introduce cosmectic changes.
We'll *refuse* the patch if it changes indentation of the code or if it
does tab/space conversion or other cosmetic changes!
7. Your patch must comply with current code's indentation.
OpenBricks rule is to use a 2 spaces indentation for shell scripts and to
comply with the C code indentation of the program you're patching for
any other case. Remember that your patch against non-OpenBricks specific
software might be sent upstream some day and so, must comply with these
projects' policies.
8. Comment parts that really need it.
Comment on what you are doing and why it is safe. This makes it easier to
review and change your code if needed and also to maintain it
years/months after it has been applied. Commenting trivial code is not
required neither recommended. Comments must be English only! Do _NOT_
put your name in the code/comments you send. From the moment your patch
has been accepted and applied, you'll be mentionned in SCM log history
or in the AUTHORS file, no need to spam the code.
9. Keep the documentation updated.
If you implement new features, add or change command line switches or
modify the behavior of existing features, please do not forget to also
update the documentation.
10. Split your patch in logical modules.
If you make independent changes, try to send them as separate patches
in separate mails. Two unrelated features shouldn't come in a same patch.
Likewise, if your patch is very big, try splitting it into several
self-contained pieces. Each part can then be reviewed and committed
separately. Logical units should stay together, though, e.g. do not send
a patch for every file you change.
11. Send your patch to the openbricks-devel mailing list.
In the mail, describe in a few sentences what you've changed and why.
All mails have to be written in English only. Do not send your patch as a
reply to some other unrelated mail; compose a new message, otherwise it
will probably get overlooked. Do not compress your patch unless it is
really large. It only makes handling the patch more difficult.
If you have to compress your patch, use either bzip2, gzip or zip to
compress it, not a different format.
You have to subscribe to openbricks-devel since we've blocked postings
from non-subscribers after spam problems and because patches get reviewed
by the developers on the list. We want you to be available for discussing
your code, you might be asked to make modifications before we accept it.
Do not upload the patch to a web or FTP site, send it directly to the
mailing list. The fewer steps it takes us to get at the patch the higher
the likelihood for it to get reviewed and applied. If your patch is so
big you cannot send it by mail, try splitting it into smaller pieces.
12. Give us a few days to react.
We try to review patches as fast as possible, but unfortunately we are
constantly overloaded with work, be it OpenBricks-related or from our day
to day lives. If your patch seems to be ignored, send a reminder asking
for opinions as a reply to the original patch and mention that you got
ignored. We are interested in your work and will eventually either accept
it or reject it with an explanation of what we (dis)liked about your patch.
We will often ask you to make changes to your patch to make it
acceptable. Implement them if you want to see your patch applied and send
the update to the mailing list. Remember that updates and reminders must
be sent as replies to the original patch to preserve proper mail
threading.
Thank you!
The OpenBricks development team,