comparison vendor/zendframework/zend-stdlib/CONTRIBUTING.md @ 0:4c8ae668cc8c

Initial import (non-working)
author Chris Cannam
date Wed, 29 Nov 2017 16:09:58 +0000
parents
children
comparison
equal deleted inserted replaced
-1:000000000000 0:4c8ae668cc8c
1 # CONTRIBUTING
2
3 ## RESOURCES
4
5 If you wish to contribute to Zend Framework, please be sure to
6 read/subscribe to the following resources:
7
8 - [Coding Standards](https://github.com/zendframework/zf2/wiki/Coding-Standards)
9 - [Contributor's Guide](http://framework.zend.com/participate/contributor-guide)
10 - ZF Contributor's mailing list:
11 Archives: http://zend-framework-community.634137.n4.nabble.com/ZF-Contributor-f680267.html
12 Subscribe: zf-contributors-subscribe@lists.zend.com
13 - ZF Contributor's IRC channel:
14 #zftalk.dev on Freenode.net
15
16 If you are working on new features or refactoring [create a proposal](https://github.com/zendframework/zend-stdlib/issues/new).
17
18 ## Reporting Potential Security Issues
19
20 If you have encountered a potential security vulnerability, please **DO NOT** report it on the public
21 issue tracker: send it to us at [zf-security@zend.com](mailto:zf-security@zend.com) instead.
22 We will work with you to verify the vulnerability and patch it as soon as possible.
23
24 When reporting issues, please provide the following information:
25
26 - Component(s) affected
27 - A description indicating how to reproduce the issue
28 - A summary of the security vulnerability and impact
29
30 We request that you contact us via the email address above and give the project
31 contributors a chance to resolve the vulnerability and issue a new release prior
32 to any public exposure; this helps protect users and provides them with a chance
33 to upgrade and/or update in order to protect their applications.
34
35 For sensitive email communications, please use [our PGP key](http://framework.zend.com/zf-security-pgp-key.asc).
36
37 ## RUNNING TESTS
38
39 > ### Note: testing versions prior to 2.4
40 >
41 > This component originates with Zend Framework 2. During the lifetime of ZF2,
42 > testing infrastructure migrated from PHPUnit 3 to PHPUnit 4. In most cases, no
43 > changes were necessary. However, due to the migration, tests may not run on
44 > versions < 2.4. As such, you may need to change the PHPUnit dependency if
45 > attempting a fix on such a version.
46
47 To run tests:
48
49 - Clone the repository:
50
51 ```console
52 $ git clone git@github.com:zendframework/zend-stdlib.git
53 $ cd
54 ```
55
56 - Install dependencies via composer:
57
58 ```console
59 $ curl -sS https://getcomposer.org/installer | php --
60 $ ./composer.phar install
61 ```
62
63 If you don't have `curl` installed, you can also download `composer.phar` from https://getcomposer.org/
64
65 - Run the tests via `phpunit` and the provided PHPUnit config, like in this example:
66
67 ```console
68 $ ./vendor/bin/phpunit
69 ```
70
71 You can turn on conditional tests with the phpunit.xml file.
72 To do so:
73
74 - Copy `phpunit.xml.dist` file to `phpunit.xml`
75 - Edit `phpunit.xml` to enable any specific functionality you
76 want to test, as well as to provide test values to utilize.
77
78 ## Running Coding Standards Checks
79
80 This component uses [php-cs-fixer](http://cs.sensiolabs.org/) for coding
81 standards checks, and provides configuration for our selected checks.
82 `php-cs-fixer` is installed by default via Composer.
83
84 To run checks only:
85
86 ```console
87 $ ./vendor/bin/php-cs-fixer fix . -v --diff --dry-run --config-file=.php_cs
88 ```
89
90 To have `php-cs-fixer` attempt to fix problems for you, omit the `--dry-run`
91 flag:
92
93 ```console
94 $ ./vendor/bin/php-cs-fixer fix . -v --diff --config-file=.php_cs
95 ```
96
97 If you allow php-cs-fixer to fix CS issues, please re-run the tests to ensure
98 they pass, and make sure you add and commit the changes after verification.
99
100 ## Benchmarks
101
102 We provide benchmark tests for zend-stdlib under the directory [benchmark/](benchmark/),
103 using. [athletic](https://github.com/polyfractal/athletic). You can execute
104 the benchmarks running the following command:
105
106 ```bash
107 $ ./vendor/bin/athletic -p benchmark
108 ```
109
110 ## Recommended Workflow for Contributions
111
112 Your first step is to establish a public repository from which we can
113 pull your work into the master repository. We recommend using
114 [GitHub](https://github.com), as that is where the component is already hosted.
115
116 1. Setup a [GitHub account](http://github.com/), if you haven't yet
117 2. Fork the repository (http://github.com/zendframework/zend-stdlib)
118 3. Clone the canonical repository locally and enter it.
119
120 ```console
121 $ git clone git://github.com:zendframework/zend-stdlib.git
122 $ cd zend-stdlib
123 ```
124
125 4. Add a remote to your fork; substitute your GitHub username in the command
126 below.
127
128 ```console
129 $ git remote add {username} git@github.com:{username}/zend-stdlib.git
130 $ git fetch {username}
131 ```
132
133 ### Keeping Up-to-Date
134
135 Periodically, you should update your fork or personal repository to
136 match the canonical ZF repository. Assuming you have setup your local repository
137 per the instructions above, you can do the following:
138
139
140 ```console
141 $ git checkout master
142 $ git fetch origin
143 $ git rebase origin/master
144 # OPTIONALLY, to keep your remote up-to-date -
145 $ git push {username} master:master
146 ```
147
148 If you're tracking other branches -- for example, the "develop" branch, where
149 new feature development occurs -- you'll want to do the same operations for that
150 branch; simply substitute "develop" for "master".
151
152 ### Working on a patch
153
154 We recommend you do each new feature or bugfix in a new branch. This simplifies
155 the task of code review as well as the task of merging your changes into the
156 canonical repository.
157
158 A typical workflow will then consist of the following:
159
160 1. Create a new local branch based off either your master or develop branch.
161 2. Switch to your new local branch. (This step can be combined with the
162 previous step with the use of `git checkout -b`.)
163 3. Do some work, commit, repeat as necessary.
164 4. Push the local branch to your remote repository.
165 5. Send a pull request.
166
167 The mechanics of this process are actually quite trivial. Below, we will
168 create a branch for fixing an issue in the tracker.
169
170 ```console
171 $ git checkout -b hotfix/9295
172 Switched to a new branch 'hotfix/9295'
173 ```
174
175 ... do some work ...
176
177
178 ```console
179 $ git commit
180 ```
181
182 ... write your log message ...
183
184
185 ```console
186 $ git push {username} hotfix/9295:hotfix/9295
187 Counting objects: 38, done.
188 Delta compression using up to 2 threads.
189 Compression objects: 100% (18/18), done.
190 Writing objects: 100% (20/20), 8.19KiB, done.
191 Total 20 (delta 12), reused 0 (delta 0)
192 To ssh://git@github.com/{username}/zend-stdlib.git
193 b5583aa..4f51698 HEAD -> master
194 ```
195
196 To send a pull request, you have two options.
197
198 If using GitHub, you can do the pull request from there. Navigate to
199 your repository, select the branch you just created, and then select the
200 "Pull Request" button in the upper right. Select the user/organization
201 "zendframework" as the recipient.
202
203 If using your own repository - or even if using GitHub - you can use `git
204 format-patch` to create a patchset for us to apply; in fact, this is
205 **recommended** for security-related patches. If you use `format-patch`, please
206 send the patches as attachments to:
207
208 - zf-devteam@zend.com for patches without security implications
209 - zf-security@zend.com for security patches
210
211 #### What branch to issue the pull request against?
212
213 Which branch should you issue a pull request against?
214
215 - For fixes against the stable release, issue the pull request against the
216 "master" branch.
217 - For new features, or fixes that introduce new elements to the public API (such
218 as new public methods or properties), issue the pull request against the
219 "develop" branch.
220
221 ### Branch Cleanup
222
223 As you might imagine, if you are a frequent contributor, you'll start to
224 get a ton of branches both locally and on your remote.
225
226 Once you know that your changes have been accepted to the master
227 repository, we suggest doing some cleanup of these branches.
228
229 - Local branch cleanup
230
231 ```console
232 $ git branch -d <branchname>
233 ```
234
235 - Remote branch removal
236
237 ```console
238 $ git push {username} :<branchname>
239 ```
240
241
242 ## Conduct
243
244 Please see our [CONDUCT.md](CONDUCT.md) to understand expected behavior when interacting with others in the project.