mirror of https://github.com/sonertari/SSLproxy
You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
51 lines
1.8 KiB
Markdown
51 lines
1.8 KiB
Markdown
10 years ago
|
# Development
|
||
|
|
||
|
SSLsplit is being developed on Github as [droe/sslsplit][1].
|
||
|
|
||
|
[1] https://github.com/droe/sslsplit
|
||
|
|
||
|
|
||
|
## Reporting bugs
|
||
|
|
||
|
Please use the Github issue tracker for bug reports. Including the following
|
||
|
information will allow faster analysis of the problem:
|
||
|
|
||
|
- Output of `sslsplit -V`
|
||
|
- Output of `uname -a`
|
||
|
- Exact command line arguments used to run SSLsplit
|
||
|
- The NAT redirection rules you are using, if applicable
|
||
|
|
||
|
Before submitting a bug report, please make sure that running `make test` from
|
||
|
a git checkout produces no failed unit tests on your system.
|
||
|
|
||
|
|
||
|
## Contributing patches
|
||
|
|
||
|
For patch submissions, please send me pull requests on Github. If you have
|
||
|
larger changes in mind, feel free to open an issue first to discuss
|
||
|
implications. If you are interested in contributing and don't know where to
|
||
|
start, take a look at the [open issues][2]. In particular, [porting features
|
||
|
over to not yet supported platforms][3] is always very much appreciated. When
|
||
|
submitting code, even though it is not a requirement, it is still appreciated
|
||
|
if you also update the manual page and other documentation as necessary and
|
||
|
include as many meaningful unit tests for your code as possible.
|
||
|
|
||
|
[2] https://github.com/droe/sslsplit/issues
|
||
|
[3] https://github.com/droe/sslsplit/labels/portability
|
||
|
|
||
|
See `HACKING.md` for the list of contributors.
|
||
|
|
||
|
|
||
|
## Branching model
|
||
|
|
||
|
With the 0.4.10 release as a starting point, SSLsplit is using [Vincent
|
||
|
Driessen's branching model][4]. The default `master` branch points to the
|
||
|
latest tagged release, while the `develop` branch is where development happens.
|
||
|
When preparing a release, there may or may not be a `release/x.y.z` branch off
|
||
|
`develop`, but in either case, the tagged release is merged back to `master`.
|
||
|
Larger features are developed in feature branches off the `develop` branch.
|
||
|
|
||
|
[4] http://nvie.com/posts/a-successful-git-branching-model/
|
||
|
|
||
|
|