Mercurial > hg > isophonics-drupal-site
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. |