1
0

HACKING 1.5 KB

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