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

Mon May 2 17:45:31 CEST 2011

I would just like to say that everyone working with Extbase is doing a great
job! I just love the possiblity to use OOP already in a TYPO3 v4 enviroment.
Yes of course there is always bugs and missing features, but as you mention
it´s still under development. So far I think it´s amazing how much that
already has been implemented and some features are just great.

My contribution to the Extbase community has been zero but I hope to change
that in the near future!  So my conclusion is just keep up the good work and
enjoy the development of a great framework!

With regards
/Mattias

On Mon, May 2, 2011 at 4:16 PM, Bastian Waidelich <bastian at typo3.org> wrote:

> [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
>
> _______________________________________________
> TYPO3-project-typo3v4mvc mailing list
> TYPO3-project-typo3v4mvc at lists.typo3.org
> http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-project-typo3v4mvc
>

-- 
Mvh
/Mattias