[TYPO3-mvc] Why don't we suck at TYPO3?

[Bastian Waidelich]

[This posting is both by Bastian Waidelich and Sebastian Kurfürst as the 
project leads of the Extbase team]

Hey everybody,

we're responding to a blog post by Felix Oertel [1], where he is 
criticising the way TYPO3 is currently progressing. In a part of this 
post, he's also talking about Extbase; that's why we want to take the 
chance to give our opinion on this, and hopefully start a fruitful 
discussion. We're posting here, as we think a mailing list has a wider 
outreach than a blog posting, and we feel it's a better place to discuss 
things.
Note that we are not only referring to Felix' posting, but also to some 
of the comments.

Furthermore, we'll be trying to make a proposal for each of the outlined 
problems, how we would tackle and solve them.

First we'd like to emphasize that we're not annoyed by the posting and 
that we even agree to some of his points. Nevertheless, we don't share 
his pessimistic mindset. Being part of a project one tends to see the 
negative aspects of it, but there are a lot of good things happening too 
- a lot of which is not visible to the general public.

It was mentioned that Extbase is the "big transition tool", from version 
four to version five. Probably we all agree on this fact, but we now 
have to choose how to combine "the both worlds": We know Extbase is not 
as stable as it should be, and that's why we'd like to shift our focus 
to bugfixes and stability improvements (as announced on [2]).
On the other hand, this means that we will *not* backport every feature, 
as every new feature will definitely increase the number of (unfound) 
bugs in the system. We fully understand that some - including us - would 
like to work with the FLOW3 features today, in version 4 environment, 
but as explained above we think that's not the right strategy for now.
One example of this is the "Signal/Slots" feature [3], which we feel 
will add another half-finished feature to Extbase without fixing any 
bug. Furthermore, in v4 we already have Hooks, which perfecly do this 
job... although they are not as "pretty" :-)

Our Proposal: We'll create a list of features *we will NOT support* in 
the wiki, explaining why and how to work around this in custom projects.
This will hopefully clear the direction we're currently heading.


Another stated issue was that core developers do not feel responsible 
for Extbase, i.e. not proposing bugfixes. We think this not only applies 
to core developers, but to 99% of everybody using Extbase. In Gerrit we 
only had review requests by 5 people until now, although I am sure that, 
since we introduced Gerrit, 100 people have patched Extbase for their 
custom project. We are not sure if it's a problem of the Infrastructure, 
or if we did not communicate enough that Gerrit should be used by 
*everybody* [4]. Especially testing fixes is really easy now; it's just 
two clicks to apply them and it can help a lot to get a +1/-1 from 
someone testing it with a different setup, particularly for changes that 
you cannot easily foresee the side-effects for.

Do you have some ideas here? What hinders *you* in using gerrit?

For us, it's not easy to motivate people to contribute more; as we think 
one needs some "inner drive" to do that. At the first Extbase meeting on 
the Core Team Sprint besides me (Bastian), only Dmitry was there; so the 
session was pretty quick; but as a lot of sessions had happened in 
parallel, this is not surprising nor a reliable sign for lack of 
interest. Generally we think it makes sense to  do "Extbase code 
sprints", however this is best for bigger features or  refactorings. 
First off, we need to improve the day-to-day workflow.
Furthermore, we'd like to prepare quite some sessions on the Dev Days 
(together with you), to bring Extbase forward and hopefully more people 
will attend then. As soon as we are in the planning phase for it, we'll 
let you know here and collect/discuss the most pressing bugs/annoyances 
to be resolved there.

One more commitment by us: We both did not review the Gerrit changes as 
fast as it should be (some being there for about a month); that's why 
we'll commit ourselves to at least one hour per week looking through the 
open changesets, testing, providing feedback and merging.
However, this also means that we need you: If you pushed a changeset, 
please be prepared to answer our questions and submit follow-ups.

In the comments of the blog posting [5] it was mentioned that Extbase is 
missing strong leader. In fact, we're trying the opposite: While we are 
making sure that the general goals of Extbase and FLOW3 match up and 
that the aimed-at quality is assured, we do not see ourselves as the 
"main implementors" of features or bugfixes. Especially, we cannot 
create the momentum in the community to fix a bug and to share that fix. 
We can only ask everybody to do so; and would like to help reducing any 
obstacles on this way (especially using Gerrit, see above). We are not 
making Extbase, the community does. We are only the shepards.


Please don't forget that we're in a different situation than a year ago: 
We need to keep Extbase backwards compatible more than ever (a lot of 
people are using it in productive projects today). On the other hand we 
need to stay in sync with FLOW3, which is still changing a lot - and 
this conflict is not easy to solve. With the beta release of FLOW3 1.0 
this will hopefully change and we'll be able to backport all the 
important features & changes. To be able to keep existing Extensions 
running anyways, we're planning to introduce a "compatibility flag" as 
discussed in Berlin.

Our Proposal: We need to be more clear about the next features which 
will be part of Extbase; but right now, as stated above, the focus is 
definitely on *bugfixes, not features*. We try to improve our 
communication in this regard.

So let's join forces, make Extbase & TYPO3 even better and never forget 
the main goal, TYPO3 Phoenix!

Greets, Looking forward to your feedback,
Sebastian Kurfürst & Bastian Waidelich (Extbase & Fluid Project Leads)

PS: Maybe we *do* suck at doing Extbase, but the above headline was more 
twitter compatible ;-)

[1] http://foertel.wordpress.com/2011/05/01/why-do-we-suck-at-typo3/
[2] 
http://lists.typo3.org/pipermail/typo3-project-typo3v4mvc/2011-February/008539.html
[3] https://review.typo3.org/#change,1563
[4] 
http://lists.typo3.org/pipermail/typo3-project-typo3v4mvc/2011-April/009173.html