|
1
|
## 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.
|