| 1 |
27204
|
antonis.le
|
## Filing bug reports ##
|
| 2 |
|
|
|
| 3 |
|
|
Bugs or feature requests can be posted on the [GitHub issues](http://github.com/nrk/predis/issues)
|
| 4 |
|
|
section of the project.
|
| 5 |
|
|
|
| 6 |
|
|
When reporting bugs, in addition to the obvious description of your issue you __must__ always provide
|
| 7 |
|
|
some essential information about your environment such as:
|
| 8 |
|
|
|
| 9 |
|
|
1. version of Predis (check the `VERSION` file or the `Predis\Client::VERSION` constant).
|
| 10 |
|
|
2. version of Redis (check `redis_version` returned by [`INFO`](http://redis.io/commands/info)).
|
| 11 |
|
|
3. version of PHP.
|
| 12 |
|
|
4. name and version of the operating system.
|
| 13 |
|
|
5. when possible, a small snippet of code that reproduces the issue.
|
| 14 |
|
|
|
| 15 |
|
|
__Think about it__: we do not have a crystal ball and cannot predict things or peer into the unknown
|
| 16 |
|
|
so please provide as much details as possible to help us isolating issues and fix them.
|
| 17 |
|
|
|
| 18 |
|
|
__Never__ use GitHub issues to post generic questions about Predis! When you have questions about
|
| 19 |
|
|
how Predis works or how it can be used, please just hop me an email and I will get back to you as
|
| 20 |
|
|
soon as possible.
|
| 21 |
|
|
|
| 22 |
|
|
|
| 23 |
|
|
## Contributing code ##
|
| 24 |
|
|
|
| 25 |
|
|
If you want to work on Predis, it is highly recommended that you first run the test suite in order
|
| 26 |
|
|
to check that everything is OK and report strange behaviours or bugs. When modifying Predis please
|
| 27 |
|
|
make sure that no warnings or notices are emitted by PHP running the interpreter in your development
|
| 28 |
|
|
environment with the `error_reporting` variable set to `E_ALL | E_STRICT`.
|
| 29 |
|
|
|
| 30 |
|
|
The recommended way to contribute to Predis is to fork the project on GitHub, create topic branches
|
| 31 |
|
|
on your newly created repository to fix bugs or add new features (possibly with tests covering your
|
| 32 |
|
|
modifications) and then open a pull request with a description of the applied changes. Obviously you
|
| 33 |
|
|
can use any other Git hosting provider of your preference.
|
| 34 |
|
|
|
| 35 |
|
|
We always aim for consistency in our code base so you should follow basic coding rules as defined by
|
| 36 |
|
|
[PSR-1](https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-1-basic-coding-standard.md)
|
| 37 |
|
|
and [PSR-2](https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md)
|
| 38 |
|
|
and stick with the conventions used in Predis to name classes and interfaces. Indentation should be
|
| 39 |
|
|
done with 4 spaces and code should be wrapped at 100 columns (please try to stay within this limit
|
| 40 |
|
|
even if the above mentioned official coding guidelines set the soft limit to 120 columns).
|
| 41 |
|
|
|
| 42 |
|
|
Please follow these [commit guidelines](http://git-scm.com/book/ch5-2.html#Commit-Guidelines) when
|
| 43 |
|
|
committing your code to Git and always write a meaningful (not necessarily extended) description of
|
| 44 |
|
|
your changes before opening pull requests.
|