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

[Jigal van Hemert]

Hi,

On 2-5-2011 16:16, Bastian Waidelich wrote:
> 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,

Using Extbase was also promoted with arguments such as: "If you use 
Extbase for extensions in version four it will be relatively easy to 
convert them to version five [packages]". This implies that it leaving 
out features like Signal/Slots and promoting v4 hooks for this will make 
it more complicated to convert extensions.

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

This seems to be a general problem (also for me). I haven't figured out 
the why, but I don't visit gerrit as often as I should and testing 
patches (ehm... change sets) doesn't seem to be as easy as it should be. 
Perhaps the automated things somehow give the feeling of using a black 
box. Maybe it's the little things like losing votes when someone 
modifies only the commit message and people having to repeat there votes 
(I understand this from a technical point of view).
I notice there are more votes on reading only in Gerrit while in the 
core list most votes were on reading and testing.

The unfortunate result is that when simple patches like fixing an 
obvious function call in a couple of lines takes a month to get enough 
votes, this doesn't motivate the author to make more patches.

It's not something simple as making a heading red :-(
The interface of Gerrit doesn't really help. There is no easy overview 
of changes I already voted for. You can star issues, but that's it. A 
news reader has much more features to keep track of issues you're 
interested in (even if you haven't reviewed it), to sort, search, 
filter, etc.

> 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.

Because FLOW3 is still changing one can expect that a backport such as 
Extbase is also changing a lot. Backwards compatibility is not a 
priority in my opinion. I do believe that the beta state Extbase is too 
optimistic. It doesn't seem logical to me to have a backport of a piece 
of alpha software (which FLOW3 still is at this very moment) in a beta 
state.
Using Extbase-based (Extbase'd ? ;-) ) extension in production 
environment is possible, but has its risks. Upgrading the core means 
heavy testing to make sure the extension is still fully functional. That 
is the logical result of the decision to use alpha/beta software as the 
base. Nothing bad about such a decision, but one which should be made 
very consciously.

-- 
Kind regards / met vriendelijke groet,

Jigal van Hemert.