VBLADE/vblade-master/HACKING

   1 Contributions to the vblade are welcome.
   2
   3 In contributing, though, please stay true to the original simplicity
   4 of the software.  Many open source projects suffer from the "creeping
   5 feature demon" phenomenon.  If you think the vblade needs a great new
   6 feature, first seriously try to think of a way to accomplish your goal
   7 without adding to the vblade itself.
   8
   9 Patches should be clean (to the point and easy to read) and should do
  10 one thing.  (Avoid, for example, mixing style changes with substantive
  11 changes.)  Send multiple patches if necessary.  Patches should be
  12 generated with "diff -uprN" if possible, and should be designed to be
  13 applied with "patch -p1".
  14
  15 When possible, the best way to submit a patch is by sending it to the
  16 aoetools-discuss list.  You can subscribe at the aoetools project web
  17 page on sourceforge.net.
  18
  19 When you send your patch, here are some things to cover:
  20
  21   * What version of the vblade did you use to generate the patch?
  22     (Hopefully it was the latest.)
  23
  24   * What was your motivation for creating the patch?  That is, what
  25     problem does it solve?
  26
  27   * What testing did you perform to ensure that your patch did not
  28     introduce bugs and accomplished what you intended?
  29
  30   * If your changes affect the end-user experience, have you updated
  31     the vblade documentation?
  32
  33   * Is your email client able to send a patch without changing it?
  34     Many email clients and servers corrupt patches.  Please test your
  35     email chain by sending an applying a patch before sending your
  36     patch to the mailing list.