[TYPO3-v4] Minutes of the 10th meeting of the 4.7 Release Team

Oliver Hader oliver.hader at typo3.org
Sun Feb 5 11:10:15 CET 2012


Hi Jigal,

thanks for your message and thoughs on the topic.

Am 03.02.12 18:37, schrieb Jigal van Hemert:
>> - FAL - biggest solo part is on work right now
> I have asked questions about this one earlier, but there was never a
> clear answer: FAL is part of BLE; BLE is finished as a paid project and
> delivered to the client; why does it need so much work to move it from
> one branch (the incubator) to another branch (the core master)? If it's
> ready (= done done) it should be a matter of some git magic and maybe
> solving a few conflicts.

Unfortunately it was not that easy. The Git related reasons are, that
the (BLE) subprojects Vidi, Fileabstraction and ExtJS4 have been started
independently in the beginning and then merged together. Bringing this
big merge-ball back to the Core is not as simple as one might think. The
goal always should be to have features separated by scope (like "FAL
basic API", "FE rendering with FAL", etc.), only a few changes have been
forwared to the official Core until now, such as some TCEforms changes
for IRRE and t3lib_collection handling.

The FAL incubator branch (plain-fileabstraction) can be found here:
http://git.typo3.org/TYPO3v4/Incubator.git?a=shortlog;h=refs/heads/plain-fileabstraction

Additionally I want to give some feedback to the "done done" question on
this, even I was not involved in development of FAL during the BLE
phase, but am now afterwards: As mentioned the components Vidi, Media,
FAL back seen aimed to be one big ball that fits all requirements -
however these dependencies have been the trap in the end, at least if it
came to the part of reverting from ExtJS4 to ExtJS3 again.
So, back in November 2011 at the time of the delivery to BLE an own
branch was used at the Git Incubator "integration-fileabstraction" which
fulfilled the specified requirements - however that was not a ready Core
integration - so it was just "done", but not "done done" in terms of
finished, integrated and shipped with an official version.

The version of FAL that was available back then was done it terms of an
alpha or beta version, but not as a full featured rock-solid, shiny
release - it was working, but the demand of need and individual storage
drivers (like WebDAV or Amazon S3) showed that more work needs to be
done and that APIs needed to be enhanced - we had missing features at
that time.

>> - Government Package is not related to a Feature Freeze
> 
> It's not??? If you want to present it with the release of 4.7 it should
> be tested as part of 4.7. In that case it is related to a Feature Freeze.
> If it's not subject to the Feature Freeze I can predict the result
> already: the final package contents are ready a few days prior to the
> release of 4.7. Everybody is busy with the last bugfixes for this
> release; nobody takes a look at the Government Package.
> After the release government bodies take a look at the package and find
> bugs and problems (simply because it wasn't tested in a lot of different
> environments). How does that make TYPO3 look for Government bodies?

I agree that this package needs to be tested and stable in terms of a
website. However integrating features into the Government Package does
not mean to integrate new features into the Core of TYPO3 4.7. That's
why we consider this not being related to the Core's feature freeze.

One big issue that is missing here, is the localization to English,
currently the Government Package is only available in German.

>> The ExtJS 4 migration has been dropped and reverted. Therefore the whole
>> VIDI, and new File-Module, Custom Record Tree ist out of scope.
> 
> There are still questions about how this happened. The ExtJS 4 migration
> was not part of the BLE project, yet there are three subprojects who
> depend on this !?!?
> If they were completed and delivered (= done done), how could it be that
> nobody (neither developers, testers and client) didn't notice that the
> rest of the TYPO3 backend had serious problems because of the ExtJS 4
> migration?

I'm not totally sure how this was done in the
"integration-filabstraction" branch - but I think Vidi had a ExtJS4
replacement of the ExtJS sources done by a hook. Vidi was targeted as
the new shiny list module substitute, however during the development it
only was toching the file and media part. To enable Vidi to be the thing
it was planned for, ExtJS4 needed to be the "spread" in the Core and
that was the beginning of the problems that were summarized in the
"lesson learned section" in the recent 4.7 development report [1].

> It wasn't about a list of well hidden features which didn't work any
> more; the page tree, the extension manager and loads of other often used
> parts were broken.
> It simply against all logic that the ExtJS4 migration was not part of
> BLE, yet three parts of BLE depended on it. Then you either can't
> deliver these parts because they don't work with ExtJS3 or you can't
> deliver these parts because the ExtJS4 stuff they need breaks the rest
> of the BE. It just doesn't add up somehow...

ExtJS4 migration was not a BLE requirement, but back then a requirement
for the accordant components (Vidi, Media and thus partly the FAL
visualization). So, we did not sign the contract with "we use ExtJS4 and
deliver a migration for that", but once the first line of code depended
on ExtJS4, it was automatically part of the project, yepp...

>> The one outstanding Topic is the Console-Application. Which indeed is a
>> standalone product which would need an init.php Refactoring which Oliver
>> Hader did...
>> This would has been working for the time of the BLE close-up. The
>> reasons why Olly never pushed it to Gerrit are ? I do not know :P
> 
> Why do you not know? Olly is the v4 Core Team leader, which means that
> you have regular meetings with him. If the Console-Application was on
> the list of features for 4.7 you must have discussed it with him, I
> guess...

The console part has an PHP endpoint handler, something like a REST API
on the PHP process level. This functionality was covered by a change to
the bootstrap (init.php, index_ts.php, CLI-dispatcher) and put to
t3lib_Core in the Git Incubator.

During our weekly meetings we discussed/found out that there is another
project on webservices and bootstrap refactoring and I wanted to bring
these worlds together - but failed due to lack of time (see the short
note in the accordant protocol [2]).

So, the console application is a project I'm taking care in my spare
time now, basically at weekends for some hours. The goal is, to rely or
force a change of the bootstrap in the core anymore and put the endpoint
handling to an external extension. This way the console application
might also work with versions lower than 4.7.

I'm sure I explained that in one of the release team meetings, but could
not find it in the protocols...

>> Then there are Grid-Elements. Which are finished and released to TER.
> 
> Tolleiv asked if the was the extension 'gridelements'?
> This is "just" an extension. I can understand why some functionality is
> not in the core, but there is no way that this can be presented as a
> core feature:
> - it's not shipped with the core
> - it's registered to a person (two authors mentioned), no sign that
> anyone from the core team is somehow involved or related to this
> - there is no manual
> - nit picking: it doesn't comply with CGL ('#' comments)
> From my experience it shows Joey is very dedicated to TYPO3, but as a
> personal extension no core team member will feel responsible for this
> extension.

I've written to Tolleiv's mail in this thread already - and I think
Gridelements should not be part of the Core right now since I limits to
possibility to fix "missing features" once this component gets used.
Besides that your points are valid as well, of course.

That's it for the "fact list"... I'll give feedback on the remaining
parts that are concerning leadership, management, Git problems and
communication.

Cheers,
Olly

[1]
http://news.typo3.org/news/article/current-state-of-typo3-47-development/
[2]
http://forge.typo3.org/projects/typo3v47-projects/wiki/4th_Release_Team_Meeting_TYPO3_47
-- 
Oliver Hader
TYPO3 v4 Core Team Leader

TYPO3 .... inspiring people to share!
Get involved: http://typo3.org


More information about the TYPO3-project-v4 mailing list