PageRenderTime 19ms CodeModel.GetById 16ms RepoModel.GetById 1ms app.codeStats 0ms

Plain Text | 24 lines | 18 code | 6 blank | 0 comment | 0 complexity | 98d34224f10b5967654e33df02c309ad MD5 | raw file
Possible License(s): GPL-2.0
  1. Developing Silver Lining Itself
  2. ===============================
  3. You should read and consider the `design notes <design>`_ of course.
  4. Version Control
  5. ---------------
  6. Generally I like to use forks for feature additions, and only use hg
  7. branches for things like a stable branch. So if you want to add a
  8. feature, you should fork/clone the repository and make those changes.
  9. I appreciate some note (in the description field) about what your
  10. fork's purpose is. It might simply be "to mess around with
  11. Silver Lining", but I still appreciate the note.
  12. The main repository is for integration. I'm not shy about giving out
  13. write access to this repository, if you are making consistent
  14. contributions it's easier for both of us if you can simply push
  15. directly to the main branch. This doesn't remove the utility of
  16. forks; if you are doing something that will take a while to complete
  17. or you aren't sure if it's in line with Silver Lining's design, it's
  18. still reasonable to do your own fork.