[TYPO3-mvc] [RFC] Keeping FLOW3 Compatibility

[Sebastian Kurfürst]

Hey everybody,

Thanks Felix for sharing your thoughts and concerns! I really like the
open way we're communicating about this.

I've been thinking some more about the topic of collaboration between
FLOW3 and Extbase teams, and would like to make a proposal on how we can
avoid double work.

Clear to me at the current point is that innovation is certainly not a
uni-directional thing; i.e. sometimes bugfixes or features come from the
Extbase context and are implemented in FLOW3, and sometimes the other
way around.

In the past, especially Bastian and myself have spent large efforts to
keep FLOW3 and Extbase roughly in sync, but the problem there is that we
just have limited time, and as the focus of us shifts, we will have even
less time for that. We are the bottleneck right now for keeping the both
versions in sync.

That's why I'd like to make the following proposals:

We extend the commit guidelines for both projects, Extbase and FLOW3, a
little, in a way that we include a "Extbase Issue:" or "FLOW3 Issue:"
line inside the commit message, pointing to the corresponding Extbase or
FLOW3 issue... An example for Extbase:

----------
[BUGFIX] (Validation): Foo bar baz

... some description here:

Fixes: #1234 (from the extbase issue tracker)
Releases: 4.7
FLOW3 Issue: #2943 (corresponding issue in FLOW3)
----------

Same for FLOW3:

----------
[BUGFIX] (Validation): Foo bar baz

... some description here:

Fixes: #2943 (from the FLOW3 issue tracker)
Releases: 1.1
Extbase Issue: #1234 (corresponding issue in Extbase)
----------

If there is no applicable extbase or FLOW3 issue, we just write
"(FLOW3|Extbase) Issue: not applicable" there.

This, IMHO, provides the following benefits:

  * the issue tracker serves as ToDo list for both FLOW3 and Extbase
    project members
  * Each project member in FLOW3 and in Extbase team has to *consciously
    think about the sister-project* when creating a patch.
  * ... and every reviewer thinks about it, too.
  * If we disagree if a certain feature should be back/forwardported,
    this is just part of our regular review process.
  * However, it does not block innovation in either Extbase or FLOW3, as
    it could certainly be that an issue is not fixed in FLOW3 yet while
    it is fixed in Extbase (or the other way round).


Additionally to that, I'd like to suggest that everybody from Extbase
team also subscribes to the Phoenix Core Mailing list where we post the
SCRUM Prototols:
http://lists.typo3.org/pipermail/typo3-team-core-v5/2012-February/thread.html
-- it's just one email a day, and this way you get a better insight how
FLOW3 is currently evolving before any code is produced.

I think something like the SCRUM protocols would be also very helpful
for Extbase, as it is a way to discuss bigger changes *before* they are
implemented -- and this is sometimes just necessary I think. Though I
have no good idea on how we can practically do something like this, as I
feel that the Extbase team is much more loosely coupled than the FLOW3
team. Does anybody have a suggestion here?


SUMMARY
======

In a nutshell, I propose:

  * changing the commit message policy a little, creating tracking
    issues for the other sister-project
  * read the scrum protocols of FLOW3 Devs
  * try to set up something similar like the Scrum protocols for Extbase
    (though I have no idea yet how this could practically work)


What do you think about these ideas?

Comments are very welcome :)

Greets, Sebastian