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