@@ -27,10 +27,24 @@ Core Team Member Responsibilities
27
27
28
28
Core Team members are unpaid volunteers and as such, they are not expected to
29
29
dedicate any specific amount of time on Symfony. They are expected to help the
30
- project in any way they can, from reviewing pull requests, writing documentation
31
- to participating in discussions and helping the community in general, but their
32
- involvement is completely voluntary and can be as much or as little as they
33
- want.
30
+ project in any way they can. From reviewing pull requests and writing documentation,
31
+ to participating in discussions and helping the community in general. However,
32
+ their involvement is completely voluntary and can be as much or as little as
33
+ they want.
34
+
35
+ Core Team Communication
36
+ ~~~~~~~~~~~~~~~~~~~~~~~
37
+
38
+ As an open source project, public discussions and documentation is favored
39
+ over private ones. All communication in the Symfony community conforms to
40
+ the :doc: `/contributing/code_of_conduct/code_of_conduct `. Request
41
+ assistance from other Core and CARE team members when getting in situations
42
+ not following the Code of Conduct.
43
+
44
+ Core Team members are invited in a private Slack channel, for quick
45
+ interactions and private processes (e.g. security issues). Each member
46
+ should feel free to ask for assistance for anything they may encounter.
47
+ Expect no judgement from other team members.
34
48
35
49
Core Organization
36
50
-----------------
@@ -145,6 +159,14 @@ A Symfony Core membership can be revoked for any of the following reasons:
145
159
* Willful negligence or intent to harm the Symfony project;
146
160
* Upon decision of the **Project Leader **.
147
161
162
+ Core Membership Compensation
163
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
164
+
165
+ Core Team members work on Symfony on a purely voluntary basis. In return
166
+ for their work for the Symfony project, members can get free access to
167
+ Symfony conferences. Personal vouchers for Symfony conferences are handed out
168
+ on request by the **Project Leader **.
169
+
148
170
Code Development Rules
149
171
----------------------
150
172
@@ -169,7 +191,7 @@ Pull Request Merging Policy
169
191
170
192
A pull request **can be merged ** if:
171
193
172
- * It is a :ref: `minor change <core-team_minor -changes >`;
194
+ * It is a :ref: `unsubstantial change <core-team_unsubstantial -changes >`;
173
195
* Enough time was given for peer reviews;
174
196
* It is a bug fix and at least two **Mergers Team ** members voted ``+1 ``
175
197
(only one if the submitter is part of the Mergers team) and no Core
@@ -178,12 +200,20 @@ A pull request **can be merged** if:
178
200
``+1 `` (if the submitter is part of the Mergers team, two *other * members)
179
201
and no Core member voted ``-1 `` (via GitHub reviews or as comments).
180
202
203
+ .. _core-team_unsubstantial-changes :
204
+
205
+ .. note ::
206
+
207
+ Unsubstantial changes comprise typos, DocBlock fixes, code standards
208
+ fixes, comment, exception message tweaks, and minor CSS, JavaScript and
209
+ HTML modifications.
210
+
181
211
Pull Request Merging Process
182
212
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
183
213
184
- All code must be committed to the repository through pull requests, except for
185
- :ref: `minor change <core-team_minor -changes >` which can be committed directly
186
- to the repository.
214
+ All code must be committed to the repository through pull requests, except
215
+ for :ref: `unsubstantial change <core-team_peripheral -changes >` which can be
216
+ committed directly to the repository.
187
217
188
218
**Mergers ** must always use the command-line ``gh `` tool provided by the
189
219
**Project Leader ** to merge pull requests.
@@ -205,6 +235,90 @@ following these rules:
205
235
Getting the right category is important as it is used by automated tools to
206
236
generate the CHANGELOG files when releasing new versions.
207
237
238
+ .. tip ::
239
+
240
+ Core team members are part of the ``mergers `` group on the ``symfony ``
241
+ Github organization. This gives them write-access to many repositories,
242
+ including the main ``symfony/symfony `` mono-repository.
243
+
244
+ To avoid unintentional pushes to the main project (which in turn creates
245
+ new versions on Packagist), Core team members are encouraged to have
246
+ two clones of the project locally:
247
+
248
+ #. A clone for their own contributions, which they use to push to their
249
+ fork on GitHub. Clear out the push URL for the Symfony repository using
250
+ ``git remote set-url --push origin dev://null `` (change ``origin ``
251
+ to the Git remote poiting to the Symfony repository);
252
+ #. A clone for merging, which they use in combination with ``gh `` and
253
+ allows them to push to the main repository.
254
+
255
+ Upmerging Version Branches
256
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~
257
+
258
+ To synchronize changes in all versions, version branches are regularly
259
+ merged from oldest to latest, called "upmerging". This is a manual process.
260
+ There is no strict policy on when this occurs, but usually not more than
261
+ once a day and at least once before monthly releases.
262
+
263
+ Before starting the upmerge, Git must be configured to provide a merge
264
+ summary by running:
265
+
266
+ .. code-block :: terminal
267
+
268
+ # Run command in the "symfony" repository
269
+ $ git config merge.stat true
270
+
271
+ The upmerge should always be done on all maintained versions at the same
272
+ time. Refer to `the releases page `_ to find all actively maintained
273
+ versions (indicated by a green color).
274
+
275
+ The process follows these steps:
276
+
277
+ #. Start on the oldest version and make sure it's up to date with the
278
+ upstream repository;
279
+ #. Check-out the second oldest version, update from upstream and merge the
280
+ previous version from the local branch;
281
+ #. Continue this process until you reached the latest version;
282
+ #. Push the branches to the repository and monitor the test suite. Failure
283
+ might indicate hidden/missed merge conflicts.
284
+
285
+ .. code-block :: terminal
286
+
287
+ # 'origin' is refered to as the main upstream project
288
+ $ git fetch origin
289
+
290
+ # update the local branches
291
+ $ git checkout 6.4
292
+ $ git reset --hard origin/6.4
293
+ $ git checkout 7.2
294
+ $ git reset --hard origin/7.2
295
+ $ git checkout 7.3
296
+ $ git reset --hard origin/7.3
297
+
298
+ # upmerge 6.4 into 7.2
299
+ $ git checkout 7.2
300
+ $ git merge --no-ff 6.4
301
+ # ... resolve conflicts
302
+ $ git commit
303
+
304
+ # upmerge 7.2 into 7.3
305
+ $ git checkout 7.3
306
+ $ git merge --no-ff 7.2
307
+ # ... resolve conflicts
308
+ $ git commit
309
+
310
+ $ git push origin 7.3 7.2 6.4
311
+
312
+ .. warning ::
313
+
314
+ Upmerges must be explicit, i.e. no fast-forward merges.
315
+
316
+ .. tip ::
317
+
318
+ Solving merge conflicts can be challenging. You can always ping other
319
+ Core team members to help you in the process (e.g. members that merged
320
+ a specific conflicting change).
321
+
208
322
Release Policy
209
323
~~~~~~~~~~~~~~
210
324
@@ -216,13 +330,6 @@ Symfony Core Rules and Protocol Amendments
216
330
The rules described in this document may be amended at any time at the
217
331
discretion of the **Project Leader **.
218
332
219
- .. _core-team_minor-changes :
220
-
221
- .. note ::
222
-
223
- Minor changes comprise typos, DocBlock fixes, code standards
224
- violations, and minor CSS, JavaScript and HTML modifications.
225
-
226
333
.. _`symfony-docs repository` : https://github.com/symfony/symfony-docs
227
334
.. _`UX repositories` : https://github.com/symfony/ux
228
335
.. _`fabpot` : https://github.com/fabpot/
@@ -263,3 +370,4 @@ discretion of the **Project Leader**.
263
370
.. _`mtarld` : https://github.com/mtarld/
264
371
.. _`spomky` : https://github.com/spomky/
265
372
.. _`alexandre-daubois` : https://github.com/alexandre-daubois/
373
+ .. _`the releases page` : https://symfony.com/releases
0 commit comments