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