File: HACKING

package info (click to toggle)
vblade 24-3
  • links: PTS, VCS
  • area: main
  • in suites: buster
  • size: 364 kB
  • sloc: ansic: 1,299; sh: 633; makefile: 58
file content (36 lines) | stat: -rw-r--r-- 1,544 bytes parent folder | download | duplicates (3)
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
Contributions to the vblade are welcome.

In contributing, though, please stay true to the original simplicity
of the software.  Many open source projects suffer from the "creeping
feature demon" phenomenon.  If you think the vblade needs a great new
feature, first seriously try to think of a way to accomplish your goal
without adding to the vblade itself.

Patches should be clean (to the point and easy to read) and should do
one thing.  (Avoid, for example, mixing style changes with substantive
changes.)  Send multiple patches if necessary.  Patches should be
generated with "diff -uprN" if possible, and should be designed to be
applied with "patch -p1".

When possible, the best way to submit a patch is by sending it to the
aoetools-discuss list.  You can subscribe at the aoetools project web
page on sourceforge.net.

When you send your patch, here are some things to cover:

  * What version of the vblade did you use to generate the patch?
    (Hopefully it was the latest.)

  * What was your motivation for creating the patch?  That is, what
    problem does it solve?

  * What testing did you perform to ensure that your patch did not
    introduce bugs and accomplished what you intended?

  * If your changes affect the end-user experience, have you updated
    the vblade documentation?

  * Is your email client able to send a patch without changing it?
    Many email clients and servers corrupt patches.  Please test your
    email chain by sending an applying a patch before sending your
    patch to the mailing list.