[TYPO3-mvc] [RFC] Keeping FLOW3 Compatibility

[Claus Due]

Hi Sebastian - and everybody,

> first off, thanks very much for the recent activity in Gerrit on Extbase
> -- great to see that so many people contribute in it!

And it's great to have _you_ back as well. We missed you there for a couple of months :)

> Personally, my focus has shifted a little more towards FLOW3, so that I
> don't have time anymore to look through every single changeset in gerrit
> on Extbase. Still, it is very important to me that we stay in sync
> feature-wise and bugfix-wise where it makes sense.

I agree, but we should precisely define "where it makes sense". More about this later.

> Furthermore, I feel personally also responsible for Extbase code
> quality; that's why I'm down-voting many topics in Gerrit without unit
> tests. Sorry!

I hope nobody takes a down-vote personally (you really shouldn't). Here though, you touch on something that I think we could streamline a lot by having a QA person in Extbase. Effectively somebody responsible for the current state of the git master and code coverage of the unit tests. A lead dev if you will.

Just as an example, I truly and sincerely suck at writing unit tests but I like to think that I don't suck nearly as much at writing effective code. So while I learn this unit testing heebajeebee my unit tests are bound to be basic - and I would hate to see this become a blocker.

I suppose if people are having trouble with git or getting into the whole Gerrit logic, slapping on a unit test requirement could demotivate people. Not me, don't worry, I see the point of unit tests even if I can't write a good one myself yet. But such a requirement does make Extbase development a lot less flexible and to me, this should be a big concern of ours.

> An example for a feature which could easily be forward-ported to FLOW3:
> https://review.typo3.org/#change,7148

Excellent example also of my inability to write unit tests :) If somebody wants to complete that change with a few tests that would make me very happy.

> Another example for such a feature relevant to FLOW3 would be:
> https://review.typo3.org/#change,4440

You definitely know better than me what works for FLOW3 but the main reason for doing the change above was that we don't have namespaces in Extbase and needed a more FLOW3-shorthand-like way of using custom validators. Would it not almost take more to do the same if you use fx Vendor\Package\ValidatorName instead of Namespace\ValidatorName?

But I digress. :)

> That's why I'd suggest that for every feature / bugfix in this area
> which takes place, we should at least make sure that a bug report on
> http://forge.typo3.org/projects/package-typo3-flow3/issues exists --
> linking the extbase and the FLOW3 issue together. This way, this is some
> kind of "TODO" list for FLOW3 developers, and also enables the FLOW3
> team to learn from real-world experiences made with Extbase.

Excellent point! This could be the practical solution to a back-communication problem. As long as this does not become a reason for FLOW3 gurus like yourself to no longer stay interested and active in Extbase ;) v4 still has a lot of good years to come.

> If there are bigger changes in Extbase where you are not sure if a
> corresponding technology exists in FLOW3, you can quickly grab the
> developers (including me) inside the #flow3 channel on irc.freenode.net.

I for one will be using that channel a lot more in the future.

> Furthermore, we should ensure that changes in these areas are covered
> with unit / functional tests, as we have quite some in this area
> already, and we should make sure that the test coverage doesn't shrink
> because of "so many features so little time"...

I would love this - but don't you think it makes sense to have a person dedicated to QA in order to keep things flowing and loosen up commit restrictions a little?

> Do you think that makes sense? On one side, I don't want to slow down
> Extbase development, on the other side, I think we need to invest some
> time thinking about the FLOW3 compatibility. Creating the respective
> issues doesn't sound like too much work for me, but I think it will help
> us to stay more in sync.

One quick point about the four areas you mention: I agree about which ares should be kept in sync but would add that in those areas there are already parts that are not in sync, for example due to differences in annotation styles. So my personal opinion is that we should be less religious about FLOW3 sync line-for-line and focus instead on the end user experience (a point which Sebastian has already brought up and which I like very much).

Yes to the double issues, absolutely! This could also let us track if some behavior in FLOW3 changes. A point though - shouldn't the opposite also be done if for example there is a bug detected in FLOW3's error handling - Extbase would need a forge issue as well?

Perhaps we could find a way to make it very clear exactly when such a double issue is required so there is no room for error? Can redmine for example do something based on an issue's category...?

And to avoid slowing down development I propose either having a dedicated QA person or allowing unit tests to be improved in, just as an example, sprints. I think this could keep the momentum up without disconnecting code and quality. All we would really need is a way to coordinate when/where unit tests need improvement.

Can Fuzzing perhaps do something for us Extbase folks in that regard? ;)

--
Cheers,
Claus
http://fedext.net