git.typo3.org

Several discussions started in the typo3-core mailing lists raising the question about how to deal with the "backports" in our TYPO3v4 core branches. See threads:

1. "[TYPO3-core] Gerrit submission process for multiple branches" from 30.10.2011 (Francois Suter)
2. "[TYPO3-core] Change procedure revisited" from 19.11.2011 (Jigal van Hemert)

for a more in depth discussion about it.

Goal¶

We need some "official" documentation on how our team works, who has which responsabilities and what to expect from the core team, from the release managers (and what not to expect).

What we already have¶

1. A technical documentation on backporting a change to other branches

1. The rules:
   1. first "push" the request to latest version where the patch applies (in general this should be "master")
   2. already include "Releases:" tag in the commit message indicating to which other releases this fix will apply
   3. only after the full review and merge has happened there, the backporting begins

This is where the "gray zone" starts, because it's not documented who / when / why should do the backporting and what has to be considered while doing that.

What we need¶

Starting with these facts we should document the whole process. Following Jigal's suggestion of using the clear terms "COULD", "SHOULD" and "MUST" (RFC-like) to indicate what is mandatory and what is optional.

We should also consider or check how FLOW3 team is dealing with this (new) challenge, as they are also now maintaining 1.0 while working on 1.1.

References¶

1. http://www.typo3-anbieter.de/typo3-merges/
2. http://bit.ly/flow3-merged-changes