News

Road to 6.2: a hot feature freeze phase (39 comments)

Added by Ernesto Baschny almost 6 years ago

Since the release of beta1, the 6.2 development entered a phase called "feature freeze". This means that we stop adding new features at will and only do that for very special circumstances and always in agreement with the release manager.

The focus is now on:

  • fixing bugs in our new features
  • stabilize new APIs
  • increase performance
  • enhance the core's "best practice" character (i.e. by correctly using our own API)
  • improvements and fixes in the backend styling

Features after feature freeze?

Yes, it is not uncommon that "last features" still enter after beta1, but these have to be clearly agreed upon with the release manager and be in line with the already proposed goals for 6.2.

What makes this release special is the LTS character. We know that this is a release that will be the most used for the next three years. We learned that from the 4.5 release. This doesn't mean that we just stuff in as much as we can, we still need to consider every addition with care.

So here is the current state of exceptions for feature freeze and their explanation, which are targeted for "beta2", to be released on November, 12th:

File Abstraction Layer

The FAL gained essential features last minutes before feature freeze in splitting up sys_file and sys_file_metadata and allowing the latter to be localized. Despite fixing bugs and improving performance, we want to finish up the work required for a migration from DAM, mainly these two topics:

  • Indexing refactoring, also providing a Extractor Interface (#52841, also outlined in this blueprint)
  • Introduce Signals in IndexRecordRepository and MetaDataRepository: (#52952)
  • 'placeholder' feature in TCEforms should recurse into relations (#52630). This is why you currently see "0" as a placeholder in file relations in beta1. We need this recursion feature!

Categorization API

We already make much better use of the categorization API introduced with TYPO3 6.0. Pages and Content Elements can be categorized by default, categories can be sorted in the backend and we allow multiple category fields per table.

To make the categorization system usable for integrators we've added a categories based menu (#51161). To really complete the usage of system categories in the Core in the frontend, there is already a very mature feature not merged to the core yet, but which might be included in beta2:

  • Provide a menu of categorized content elements (#52137)

Logging API

The goal setup in the kickoff for 6.2 was to make the core use the logging API introduced in 6.0. Unfortunately this goal was not achieved yet due to it's complexity.

  • Deprecate devLog (#52694). This is just a tiny part of the big plan, but nevertheless an important one. Due to conceptual questions which popped up during implementation and review phase, we agreed to allow this change to be merged only if it is based on an approved concept beforehand (in form of a Blueprint).
  • Graylog Logger won't be part of 6.2: Steffen Müller is not able to finish up a "solid" work during the next time, so he decided to ship this work as an extension in TER.

OpenID

  • Wizard to add OpenID to backend user (#49310). This was part of an ongoing process of fixing OpenID login problems and was already merged (and will be part of beta2).

RSA-Auth

The rsaauth extension will be used more intensively because "saltedpasswords" is now the new default authentication method for the backend. This extension has some conceptual drawbacks which doesn't allow us to fix easily some very annoying bugs.

  • Nicole Cordes (who gained lots of rsaauth expertise while working on our saltedpasswords tasks) will work on some refactoring of this extension to provide a more universal API, allowing us to fix issues like #34568 and making it more useful for other extensions (i.e. a javascript method to register any forms and fields requiring "encryption" - not only our login forms).

Package Management

This conceptually intrusive feature added in beta1 will still need some love and care and maybe one or two additional API changes.

One already known required feature:

  • Allow the activation of packages during runtime (#53015) - this is required for scenarios where the static "PackageStates" is not enough and you require a different set of activated packages in development and production systems (formerly one could add extensions to the "extList" by AdditionalConfiguration.php which is not possible with the new Packagemanagement yet).

Usability Improvements

The UX team with Jens, Lars and Martin worked on identifying lots of "buggy" styling issues in the 6.2 backend (and Install Tool). We will target the most prominent issues as good as we can to be able to at the end provide a consistent and solid backend for our users.

The goal currently is not to completely change the backend look and feel, but to either finish up open and doable tasks or revert certain unfinished areas.

Speed Speed Speed

During the last code sprint before feature freeze and still being debated in the team is the need to regain performance in TYPO3. We are aware that since 4.5 a lot of refactoring made the code cleaner and more robust, but in certain scenarios the performance got worse from release to release. Due to the fact that releases between the LTS releases (4.6, 4.7, 6.0, 6.1) were not used so much by major installations, this performance degradation hasn't come to the attention, and most will be hit by it first time when upgrading from 4.5 to 6.2.

To minimize the impact the CMS team is currently working hard (i.e. in #52949) to identify and potentially solve the most important performance issues.

Benchmarking is a difficult topic, and we currently have no standardized way of benchmarking TYPO3 Core to identify exact commits which affected the performance. The difficulty lies in setting up correct installations and creating useful scenarios which can provide useful information at the end. The art lies in being able to interprete the statistics generated by benchmarking tools and it's impact.

The idea of hosting a "Performance Code Sprint" popped up. It could be something to be planned for November.

But in general we invite every performance interested TYPO3 developer or integrator to help us with profiling, identifying bottlenecks, and working on solutions - instead of simply complaining about it. Let's look into the future and not in the past.

Help us make 6.2 rock!

We invite every user, developer, integrator, web agency and interested party to help us make 6.2 the best release ever. Report bugs, share your performance findings, discuss solutions with the team (i.e. through the mailing list / forum typo3.teams.core or the core issue tracker): participate! It's not a CMS from the "Core Team", it's a work from the whole TYPO3 community!

We already have lots of very nice features included, and it's up to the help of you to make it also a very stable product, something which the TYPO3 CMS has a long reputation of being.

Road to 6.2: Let's finish it! (29 comments)

Added by Ernesto Baschny almost 6 years ago

The goal of this weeks Code Sprint in Hannover will be: "Let's finish it". The motto resumes the essence of the current activity. Next week we will release TYPO3 6.2 LTS beta1: A milestone which will mark the beginning of the feature freeze phase in our development cycle. After that we won't be adding "new features" but will focus on improving the existing functionality with stabilization, bug fixing, clean-ups - working towards a stable and mature "6.2.0" release in December.

In preparation for this Code Sprint, we would like to have bunch of "ready to go" review requests already pending (or matured) in our review system (Gerrit). This will allow the team jointly review, discuss, improve and finally merge this new functionality in the core.

Some ideas that already matured but need finishing:

Responsive images

During the T3DD a Workshop initiated by Ingo Schmidt kickstarted the work on being able to render "responsive images" in the frontend. The concept was documented in issue #50075. Work is being improved in review 22052 which already contains a bunch of incrementally improved patchsets. If you are interested in this feature, consider taking a look at the current implementation, comment on it, test it out and give your reviewing vote.

Providing Backend Layouts

Currently it's only possible to provide "backend layouts" as records that are stored in the database. To be able to share "backend layouts" together with ready made themes (as proposed by the themes extension) or to be able to include them in a workflow of deployment through a versioning system (text files), a new mechanism for providing these layouts is being seeked. This is being developed in issue #37208 and review 11804. Currently Jo Hasenau is working on implementing the latest concept, implementing it as "data providers".

File Abstraction Layer Multilanguage

We want to make the meta data of files translatable. Read more about it in the corresponding blueprint. Steffen Ritter is working on it, and first want to clean up some API issues (see review 23839). To see where this is heading, checkout his fal62 branch. Help reviewing and testing is required.

Composer / Package management support

We strive to have a modern "Package management" inspired in the Flow components, including full composer support (#47018). Thomas Maroschik already has a work in progress (WIP), but this still needs refinement, improvements and conceptual clarifications. If you are interested in this matter, please consider reviewing the current state and joining discussions. Tom will be present in the Code Sprint and will work on finishing up this foundation during these days.

Store Sessions outside the DB

In order to improve scalability, Thorsten Kahler wants the Core to be able to store the session information outside the database, thus minimizing (or even removing) MySQL queries on every hit. In order to do so the concept should create an API where different "session storage backends" can be implemented and plugged in. See #51731 for the current work in progress. Thorsten will be present in the Core Sprint to work with the team on finishing this feature.

Other ideas

A further compiled list of other pending issues might help getting an idea on where one can still help in our journey to 6.2. Especially the "green" ones already contain Review Requests.

Other new features might also still come in, and only require to pass the regular reviewing process. Get creative, form a team, and get in touch with the release team () about your initiative.

Supporting the Code Sprint

The T3A budget for the TYPO3 CMS team is able to cover the expenses for traveling to Hannover and everybody's rooms in the Hotel. Bitmotion is sponsoring and hosting the Code Sprint location and infrastructure.

But the crew is also welcoming sponsoring for drinks, food, snacks, coffee and those "little things" that make a coder code more efficiently. So if you cannot help with coding, reviewing, testing or giving technical feedback, consider sponsoring these activators. Please contact me ("Ernesto Baschny":) before sponsoring something, so that we can organize what we need (and don't end up with 20 crates of Club Mate but no food).

Decision time for the 6.2 Release (41 comments)

Added by Ernesto Baschny about 6 years ago

It's been some weeks since the last news on the state of development for the TYPO3 6.2 release. The last month we've seen a natural decrease of development activity mainly due to the holiday season in Western Europe. Nevertheless we focused on certain tasks centered mainly around code sprints.

FAL Code Sprint

At the start of August we had a FAL Code Sprint, which was meant to improve the API, work on bugs and fix some open loose ends. We teamed up with Steffen Ritter, Andreas Wolf, Helmut Hummel, Olly Hader, Nicole Cordes. Our new FAL force Frans Saris joined us and was eager to work on the FAL code and our host Torsten Schrade from the Akademie für Wissenschaften also joined our efforts.

The result of the code sprint left us with some mixed feelings because we got some important concept discussed but we still have lot of work to do. We kick started lots of important fixes, especially in the permissions area (#50872, #51004).

Our new FAL contributor Frans Saris dedicated some time to work on the "missing files" and "deleted flag" handling (#50827, #51097, #50876, #48182).

We discussed the need of the "Default Storage 0" and the issues involved with that (#45498, #50828) and Storages in general (#50871, #49842).

Nicole Cordes tackled lots of Unit Tests failing, especially under Windows (#39715).

The class hierarchy was given some thoughts (#50867), and again the need to localize FAL records was discussed and we've got some more infos on that in #49842.

Extbase Code Sprint and Functional Framework

Last weekend we had a Extbase Workspaces code sprint in Stuttgart, and we will certainly will soon hear more about the results. An important milestone was reached in that we now have a functional framework in place where we can easily test bigger chunks of code interacting with a complete separated database instance, configuration and set of installed extensions. This is an important asset for us to be able to enhance or fix conceptually complex areas - like workspaces or language handling. More work will now need to come to define some basic workspaces functional tests using this new framework before we are able to start really enhancing this area.

Road to big decisions

After these achievements and sprints we are heading into a very important and decisive phase in our 6.2 development. We had declared in our roadmap to deliver one last alpha by the beginning of August - which didn't made sense due to the sprints still to come and the lack of many new features to showcase.

The next step in the proposed roadmap is the first Beta version by beginning of September, which would also mark the feature freeze in our codebase for the 6.2 release.

During these last weeks of meetings we had the opportunity to discuss the current status with plenty of people. In general the feeling is that we are lacking time to really finish what people are expecting for this release. The 6.2 LTS release is such an important milestone for agencies, developers, freelancers and customers. We know that and we don't want to rush out a release that people are annoyed with for the next 3 years of support just because of lack of time to finish what we were wanting to finish.

Since the definition of our Roadmap we declared that the final date is tentative and we should declare the need (or not) to expand the development phase shortly before the feature freeze. Well, exactly this time of decisions is coming.

Code Sprint in Essen: postpone feature freeze?

Quite fitting is that all major contributors of the Core will meet in a general CMS Code Sprint in Essen, which we currently are declaring as the "Feature Freeze Sprint". It will be during these days that we will be able to decide if we stick to the roadmap or postpone the release of the feature freeze and thus also the final release, and by how much time. There have been voices to postpone the release by one month until as much as until the beginning of next year.

So currently it looks very strongly that we won't have a release during the T3CON in Stuttgart. But who knows what we are able to achieve in Essen and how the team feels after these four days. So at last with the next snapshot release at the beginning of September you will know on how the roadmap will continue: if it turns out to be one more alpha means we are not in feature freeze. If it is a beta it means: feature freeze began.

Open initiatives

To be more concrete, the following areas need more manpower until feature freeze:

  • Being able to again provide easy starter packages (i.e. Introduction and Government package). Work is somehow stalled, and just some concepts and ideas are ready, but still no code.
  • File Abstraction Layer (FAL) API and Features: We are not yet totally satisfied with the current state. Lots of work in progresses and ideas still to be concretized.
  • Logging API: Steffen Müller already gave us an insight that much more time would be required to tackle the daunting job of making the whole Core use the new logging API. Central places like "sys_log" and "sys_history" are currently very tied together.
  • Composer support: The work-in-progress from Thomas Maroschik is already very far, but will need more reviews, testing and refining until release.
  • Design foundations for backend modules: We still want to clarify if we are able to include Twitter Bootstrap into the backend (licensing question). At least we want to have a solid foundation for BE modules to work with.
  • Some more usability love could be spend in the Page Module and in the new File List

If you are interested in participating actively in one of these topics, please join our effort either by simply dropping by in the Review System or in our Core Issue Tracker. If you want to participate more actively, simple get in touch with me () or any other Core Active Contributor you know.

Thanks for you understanding and support!

Half-Time between alpha2 and alpha3 (34 comments)

Added by Ernesto Baschny about 6 years ago

We are still on track, heading now to the release of alpha3 in a couple of weeks. We are also almost reaching half-time in our development phase for 6.2. Things will start heating up on the next weeks, especially in the phase near feature freeze (September 3rd).

General Activity

Last weeks were marked by some notable absences: Benni Mack is preparing for a very personal project and is basically unavailable for Core work at least until 10th of August. Helmut Hummel is currently on holidays, but has already promised some more intensive work on TYPO3 CMS once he is back - which should be in the next couple of days.

Oliver Hader is doing some heavy weight lifting with workspaces. He is working on that area as payed projects for customers, but will at the end be able to bring back enhancements on that area to the Core. Basically he is doing general UI and performance improvements. At the same time, he is in a conceptional phase for overlay strategies (M-M, IRRE, Extbase, ...). This is a daunting and very complex area but nevertheless very important for our product. Basis for this work was the brainstorming sessions at the dkd Code Sprint. These thoughts should be the base for the changes to come, which will also be handled during the Extbase Workspaces Code Sprint (in Stuttgart from 15th to 18th of August).

On Wednesday Bastian Waidelich organized a conference call on the topic FLUID Templates and the issue on how to deal with the need of overriding individual templates / partials instead of the whole template-set. The need for a meeting was risen by the wish to synchronize the way upstream Fluid will deal with it and how we will deal with it in CMS - which should be more or less in line and compatible to each other. Bastian promised some information posted on the mailing list, look out for it soon.

The Usability Team is trying to get the ball rolling during these last weeks after the initial kick-off meeting in Frankfurt. There is a Skype Chat where the team exchanges ideas with the Core (Felix and Ernesto). The team is searching for alternative ways of reviewing screen designs. And we took a look at the UX issues categorized last year by the team and the release team at that time. We currently are focusing on small but meaningful UX improvements for the 6.2 release.

During the last weekend Nicole hosted the PHPunit Code Sprint in Berlin. It was productive and we can expect some more detailed report soon from one of the involved parties.

Reimbursements

Speaking of Code Sprints, there were some questions regarding Reimbursements of the TYPO3 Active Contributor Meetings in Nürnberg (which was not explicitly considered in our Budget Application, but was covered as a "Code Sprint") and the Meetings before the Developer Days (which had a separate Budget together with the Flow/Neos team). The Budget Numbers, required to be printed on all invoices:

  • TYPO3 CMS Budget: #4000
  • TYPO3 Active Contributor Meeting T3DD: #4080

We currently have spend ca €2.600 for the meeting in Nürnberg. For the Developer Days we have calculated with a limit of €470 per person to cover the required expenses (Travel, Hotel, DevDays Ticket). We currently do not know how many participants from the Neos/Flow team will ask for reimbursement. We know that traditionally from the CMS team several developers get sponsored by their agencies / employers. So we decided to rise the limit to €550 per person and will probably also be able to spend a bit more on individual cases. Just get in touch with Ernesto Baschny in case of doubt.

Coding Activity in the 6.2 branch

Since Alpha2 we have merged some interesting stuff unique to 6.2.

One notable change was the introduction of ReST documentation for System Extensions! 

Another nice enhancement is the introduction of the ApplicationContext, a direct backport from Flow. This allows TYPO3 to understand in which context ("Development", "Production" etc) the current run is made allowing some components to behave differently (i.e. Logging, Caching, Exception Handling etc).

Not yet merged into the core but in a very mature "work-in-progress" (WIP) state is the introduction of the Package Management API by Thomas Maroschik. This will be a base functionality of TYPO3 allowing the EM to handle extensions just like Flow handles packages while integrating nicely with Composer Package Management. It's worth to take a look at the current state and give some feedback directly to the team!

Planned Activity

Smooth Migration Agency Sprint

Steffen Ritter is working hard on the organization of the first TYPO3 Smooth Migration Agency Sprint. The goal is to identify and tackle more potential issues with the migration from TYPO3 4.5 to 6.2 LTS.

This event will be in a format never before tried out: Not a regular "Core Contributors Code Sprint", but instead agencies sending their TYPO3 experts and working together with other agencies and supported out by two core coders (Steffen Ritter and Christian Kuhn).

The current status is that we have a letter on a TYPO3 official paper (provided by the Press Team) and will make use of the T3A to invite personally Platinum/Gold Association Members during the next days. The T3A-Shop-System will be required to process the invitations. The location is already booked (Unperfekthaus in Essen).

FAL Code Sprint

We are in a phase of planning a FAL Code Sprint to happen rather sooner than later. The goal is to stabilize the API, fix pending issues, make it more stable and provide a better ground work for extensions like "Media" to be based upon it.

The week from 5th to 8th of August is a potential candidate for the Code Sprint (during the week, to try to minimize the "lost weekends" by our fellow developers). Currently we are searching for a good location. One candidate is Mainz, the other one is Düsseldorf (WMDB). Andreas Wolf is getting in touch with the location providers.

The FAL Code Sprint explicitly is not yet about improving the "Media" Extension. Media is an extension created by Fabien Udriot and is being developed as a stand alone extension separated from the Core. It might provide a replacement for DAM, but there are no plans to integrate it into the Core. To build a team and support the Media extension development, we will try to organize a Code Sprint dedicated to it later on.

Introduction packages

As we already have explained with the release of alpha2:http://typo3.org/news/article/typo3-cms-62-lts-alpha2-released/ there were no Introduction or Government Packages build for the current development snapshot. The current development status in this area (i.e. integrate the Responsive Package) is in the hands of Benni Mack. Olly will try to get in touch with him to understand what's missing and how and who can help with it.

Stable Releases of TYPO3 CMS

We will be releasing TYPO3 CMS stable releases today (Tuesday, July 23th). This means 4.5, 4.7, 6.0 and 6.1 will get a release, which will include all fixes that were merged until the last release - which were quite a bit since the last release is now almost 2 months ago.

Keep on rocking

That's it for today. If you can help in any area, you can be sure that any help is very welcome! Simply take a task that is open (i.e. an issue to be reviewed, a new tiny feature you need, etc). Your contribution is very valuable! In case of doubt on where to help, contact the release management team (Olly Hader, Steffen Ritter, Benni Mack, Helmut Hummel, Xavier Perseguers, Ernesto Baschny) and explain your motivations or your special interest areas and we will find out something nice for you to work on.

Kind Regards,
Ernesto Baschny - Release Manager TYPO3 CMS 6.2 LTS

LTS Smooth Migration Subproject (836 comments)

Added by Ernesto Baschny over 6 years ago

Historic perspective: Deprecation Strategy

In the TYPO3 CMS world we were used to be able to upgrade from one version to the next with little to no effort. By upgrading we gain new functionality but usually the "old way" still works. This is called backwards compatibility, and TYPO3 CMS users are very spoiled to have had a high grade of backwards compatibility.

But with backwards compatibility comes the downside: The code base gets larger and larger, the "old code" needs to be further maintained (for security, tests and when considering new features or change of features / interfaces) and people (developers, integrators) get lazy in adapting to newer technologies that emerge with newer versions.

This is why several years ago (during 4.3 development back in 2009) we agreed to introduce a consistent deprecation policy: If some method / function in the Core is replaced by a new one and no longer in use (by the Core itself), it is marked as "deprecated" and can be removed two releases afterwards. This was also when the "deprecation log" was introduced.

At that time we already had lots of stuff marked as deprecated since "TYPO 3.5".

Up to version 4.5 LTS (2011) we haven't really practiced the "removal" part of the strategy consistently. In fact with 4.5 LTS we decided "for the last time" to keep all deprecated methods and start removing them in 4.6 (and later) - which is also why 4.6 is called "rebase".

Now we are in the situation that 3 years later (we had 4.6, 4.7, 6.0, 6.1) lots of methods are finally really gone. So for the first time, people upgrading from 4.5 to 6.2 will face some major breaking of their sites.

Future: Migration strategy

Considering the above situation, we are aware that this change might come to a surprise to some, and could cause some reputation loss on long time TYPO3 enthusiasts. Thus this sub-project was founded to focus on this area, considering that many users will upgrade their systems for the first time since 4.5 LTS.

We don't want to announce an unrealistic goal with our "Smooth Migration" project. So this task-force is about providing all the tools and knowledge you need to migrate your systems.

A successful upgrade consists of:

1. migration is possible in all areas
2. migration can be planned and is quotable
3. everything works out as planned

What we plan to do

Upgrade Report Extension

We will provide an "compatibility check" extension which you can install into your TYPO3 CMS 4.5 LTS.

This extensions will generate a report about the system, lining out the topics which need to be adapter for an upgrade. This report should be as detailed as possible, so it could work as an upgrade check-list for developers and integrators.

These reports can also describe the possible solution and needed changes. This is an ideal base for calculating an upgrade (for your site or for your customer).

We currently are in the phase of designing the interfaces for the "checks" to be performed and identifying the changes over the last 5 versions of TYPO3.

We will try to provide checks for all the core topics and expect agencies and extension developers to provide even more "checks" (by implementing the check-interface) to get a more comprehensive test-suite.

Steffen Ritter will kick start the extension and will need the help of the community for implementing more checks.

Rework Migration Wizards

The TYPO3 Install Tool provides "upgrade wizards" to assist the work of an upgrade.

The current user interface is sub-optimal.

The implementation is not very stable:

  • Long upgrade wizards could run out of your max_execution_time and abort on error. Half-run wizards may have undetermined states and may not be able to finish cleanly.
  • Furthermore there are no dependencies or execution ordering possible.
  • It might crash if there is an incompatible extension.

While stabilizing the install tool, the Upgrade Wizards will be reworked so that an upgrade can work out well even on big installations.

Steffen Ritter will be working on the Upgrade Wizard together with the "Install Tool" task force (Christian Kuhn and other active contributors).

Compatibility extension

There could be an extension that one can install on TYPO3 6.2 LTS which "mocks" the way older versions of TYPO3 work by providing a compatibility layer.

This extension should bring back deprecated methods. It comes with a down-side of a slower system, but could be a solution to keep some site running for three more years without going into too much trouble.

Oliver Hader is working on this extension and is glad to discuss the details with you.

Extension Developer Guidelines

The Smooth Migration Wiki will kick start the documentation for Extension-Developers providing best practices on how to support both Version 4.5 and 6.2 LTS or - if not possible - easily migrate their extensions.

The Installation and Upgrade Guide will be enhanced with a chapter on the "LTS to LTS" migration problems.

Ernesto Baschny will coordinate with the documentation team (Francois Suter) on this documentation topic.

Your help required

Many fancy extensions and functionality reside at the agencies or with freelancers in their work for their customers.

For identifying pitfalls we need as many as possible real-life test cases. For that we highly encourage volunteers to test out the new version: upgrade the system to the master branch (git) and tell us where the problems occurs and (if possible) provide the solution.

Get Agencies and users on board: Code Sprint

At the T3DD13 in Hamburg there will be a session targeted on upgrading, where we expect to meet lead-developers / deployment specialists of the agencies in the TYPO3 universe to discuss the problems they have and how we could tackle them as community.

Furthermore we are planning to organize a code sprint (more like a "meet up") in the time between Alpha3 and Beta1 (in July, 2013):

Agencies interested in upgrading their installations send one or two developers that know their problems and headaches. We meet up during the week (work-time) and try to collect, identify and solve these problems. Each agency would cover the costs for their developer themselves.

Sponsoring for location, food, drinks, amenities would be highly appreciated. Ingo Schmitt from Marketing Factory already offered to organize this event (thanks a lot for your help already!).

Summary

What we want to provide you with is a rock stable upgrade path, that will support you on upgrading any site. These can be automatic fixes to solve code base problems, or a report with "to-dos" or suggestions that need to be worked on manually. In the end you will be able to upgrade smoothly to 6.2 LTS.

If you want to help, get involved, have questions or wishes, don't hesitate to contact Steffen Ritter or get more information through the project page

Second Meeting for TYPO3 6.2 LTS Release (55 comments)

Added by Ernesto Baschny over 6 years ago

Second 6.2 Release Team Meeting - May, 24th 2013

Since I wasn't available on Thursday - our regular meeting time slot - we decided to meet on Friday at 14:00.

Participants

  • Oliver Hader (Team Leader)
  • Benni Mack (Release Manager 6.1, Co-Team Leader)
  • Xavier Perseguers (Release Manager 4.6)
  • Christian Kuhn (Q&A, Coder, Co-Release Manager 6.0)
  • Ernesto Baschny (Release Manager 4.5 + 6.2)

Later also Steffen Ritter (Release Manager 4.7) joined in the US morning. He's currently in San Francisco and will attend to the T3CON-NA together with Benni - representing our TYPO3 CMS team. Benni will host a talk around FAL (file abstraction layer) and Steffen will introduce the audience to the current Roadmap and Vision concerning the future of TYPO3 CMS.

Done this week

We went through what was done during the last week to get an overview of where we currently stand.

Forge cleanups

I went through the Usability Team Issue Tracker and updated the Target Versions there (adding TYPO3 6.2 LTS). This is the issue tracker we use to get approvals and ideas from our usability experts for improving the TYPO3 Backend and we can expect some activity here for 6.2!

On request of Steffen Müller - the leader of the Logging Project I moved his Forge subproject from the "Incubator" to "TYPO3 6.2". I will give you more details on the Logging plan in a separate article.

Created the Smooth Migration Subproject. Steffen Ritter will lead this effort which will mainly consist on creating documentation, checklists, but maybe also migration and compatibility "scripts", "extensions", etc.

"Long lost souls" reporting to duty

The first real activity was getting in touch with groups, teams and enthusiasts. I wanted to make use of the "6.2 LTS momentum" to reach out for old school contributors - some of which we haven't seen in a while. We could notice an increased enthusiasm around the development of TYPO3 CMS:

  • Jeff Segars: He has been working on a new company for a while and hasn't had much time to work on the TYPO3 Core lately - thus many new contributors might not even know him yet. He is still working with TYPO3 CMS but also on TYPO3 Flow projects. He told me he will try to get some time to work on the 6.2 development in the next time. Remembering how important his help was back at the development of 4.5 (i.e. he finished the Live Search, worked on a lot of usability improvements and was our English "native speaker" expert) I consider him to be a great asset to our current team.
  • WMDB: Peter Kühn and Mathias Schreiber reached out offering their help in the 6.2 development phase. Peter and Rupi Germann will be able to dedicate some development time - which we gladly appreciate. They are very interested in the DAM > FAL/Media Migration and in particular it's scalability and performance. We know Rupi from the old times helping out on the performance front, so I expect him to also to work on this area in general. He will probably also be helpful making sure tt_news is fully compatible. Thanks for the help, WMDB!
  • Stefan Galinski and Susanne Moog have been a bit absent from active contribution, but both are still around and will try to arrange some time to work on a patch or review from time to time. We appreciate it and we know you both do an excellent and reliable job - despite the time constraints.
  • I also had a meeting with Ben van't Ende: He's our Community Manager working on connecting the teams and keeping an "eagle eye" over what's happening in the TYPO3 community. He is very motivated now to help in the 6.2 LTS effort and will help me with communicating about it.

tools.typo3.org

The new server "tools.typo3.org" is getting ready and will in future host tools like:

Refer to this forge project where the server is being set up and will be further maintained.

Work in Progress

Install Tool

Christian Kuhn is currently working deeply in the Install Tool. This tool is one of the most important module where the first time user and the upgrader gets in touch with the new TYPO3 6.2.

Christian's plan is to make the Install Tool more robust, having a better architecture, more independence from other components of the core, never crash (i.e. no "Fatal errors") and have a much better usability.

Christian met with Felix Kopp (our usability expert) to discuss several areas of the Install Tool. One important part was how to handle the "Packages" (currently "introduction" and "government") in future. This architecture hasn't changed since its introduction with TYPO3 4.4. The vision would be that these packages are self-contained inside extensions and the Install Tool being able to detect these, auto-install them and include them in the "Step-Installer" (that's how the "1-2-3" Installer is internally called).

First progress of Christian's work is already getting shape at his personal fork TYPO3-CMS-Catharsis. He has managed to split up the huge "Installer" Class into multiple classes, got rid of some old and obsolete code (i.e. the "phpinfo" page...). He also managed to get the Install Tool being rendered through Fluid templates (without further dependencies) so structuring the templates got a lot more fun.

Next steps will be:

  • Finish this initial groundwork to make it ready to merge in the official repository so that work can continue in parallel on other areas (i.e. Steffen Ritter mentioned being interested in the Upgrade Wizards). He plans to have this ready in one or two weeks.
  • Work on the usability of the Install Tool: Christian asked us if we know "where you set the password of the install tool"?. We tried with "Basic Configuration". But it is in the "About" screen. How usable is that? I remembered also the usability of the "Create Admin User" - which is located in the "Database Analyser". Ugly, isn't it? This needed to be reworked for ages, now is the time!
  • Work on packages handling - Introduction and Government package
  • Work on a "Silent Updater" method so that the user gets redirected from bootstrap to the install tool in case something is "wrong" or "missing" in his installation.
  • Continue on the "Package Management" project together with Tom Maroschik (later Composer integration).

Google Summer of Code

As it seem, we have currently four proposals in Google Summer of Code (GSoC).

Olly noted that there is a project proposed on the topic TYPO3 Updater. Christian will take a look at it as it relates to the Install Tool.

Another interesting project is the TYPO3 Shell Proposal which still needs a mentor.

Read more about the TYPO3 participation in the Google Summer of Code 2013

Scheduled Meetings

We have a meeting scheduled with the Usability and Design Team in Frankfurt at dkd. There is currently a doodle surveying about the best day. As it seems, it will probably take place at May, 14th. We invited Robert Zierhofer from the Design Team (which is responsible for the TYPO3 web pages, banners, marketing widgets etc) to help out on the TYPO3 Backend design front. Despite the current lack of time from our UX guys (Jens and Lars) we plan to make some substantial improvements in the TYPO3 Backend for 6.2. Felix Kopp and Benni have some good visions about the general Roadmap. I'll write more details about it probably after our meeting.

Benni told us he will be flying to Hamburg in some weeks to meet with Christian Kuhn in order to discuss generic UX widgets for the Backend to provide a more consistent look & feel and ease extension and core developers work (backend "best practices").

On June 11th and 12th the Workspaces Code Sprint will take place at dkd in Frankfurt. Olly noted that unfortunately no Extbase Team member will be able to join. Anja doesn't seem to have time on these days.

Next event where many Active Contributors will be present is the TYPO3camp in Stuttgart from June 7th until 9th.

Discussions

TER Extensions migration

Xavier told us about the TER cleanup project getting in the next phase. Read details about the current step in this news. This movement is very well in line with our 6.2 Release Plan, as we require many extension authors to test their extensions with latest TYPO3 versions in order to make sure they still work in 6.1 (and thus also in the future 6.2!). The timing of this project is perfect.

We also came to the conclusion that we actively will need to reach out more to the extension authors in order to help them with the migration task. First we need to identify the "most common" extensions which need to work on latest TYPO3 CMS (i.e. powermail, templavoila, and at least all those which are included in the introduction and government packages). To get a better overview of potential extensions we will get in touch with common TYPO3 hosters in order to generate some statistics. Ernesto will try to contact Jochen Weiland and maybe someone from Domainfactory or Mittwald about this topic.

Forge "Target Versions"

I explained the proposal already send to the mailing list which is about removing the patchlevel releases from the "Target Versions" in the Forge Tracker and making the workflow easier for everybody.

The plan was approved and we will take these steps:

  1. Remove all patchlevel releases from the TYPO3 CMS project. I will try it out to avoid generating tons of notification mails. If required, I will contact the server team to do it somehow directly in the database.
  2. Provide some JSON / REST interface to fetch the merged to core information on an individual issue basis (as soon as this tool is working on tools.typo3.org).
  3. Provide / Create a Redmine plugin in order to simply display this information directly on an Issue (above the "Revisions" for example). This would provide the important (and automatically generated) information in the Issue Tracker: In which releases of TYPO3 this issue was solved, if there are Reviews pending, if we have pending backports. I will try to contact some Redmine expert or try it out myself.

Deprecation Strategy in 6.2 LTS

I argued that we need to make sure the "4.5" to "6.2" migration is not getting too difficult because of a too aggressive deprecation strategy. I recalled that in 4.5 we simply skipped the "delete deprecated methods" and postponed it to 4.6. This provided a very smooth migration from 3.8 ... 4.4 to 4.5 without substantial breaks in extensions or integrations.

One important issue is now the removal of all "stub files" in t3lib and typo3 which were deprecated in 6.0. I brought into discussion if we ought to bring them back in order to avoid several problems people might have with it. Christian is strictly against it. There are several solutions already:

  • By using the autoloader which we have since TYPO3 4.3 there is no need to "require" any individual file
  • References to EXT:cms/filename.php in callUserFunc and similar might require some analysis and maybe some fallback solution (see for example #48371 in Grid elements)

The core directory structure is now much cleaner and fun to walk through. At the end we will be able to get rid of t3lib completely. So we decided not to bring back the stub-files but keep an eye on potential problems - probably we'll get more details once we start mass-testing important extensions. I've documented this task in #48534 so that we don't forget to do it.

Olly also mentioned the planned "Compat Extension" which might be place to detect these kind of annoyances before hand.

Another issue I collected during this week was #48396. We decided to keep this kind of compatibility layer.

In general, I asked everybody to be thoughtful and attentive when it comes to removing deprecated methods. We have deprecated lots of things in 6.0 but it came out just some months ago. Simply removing them now just "because we can" is not wise considering the plan of providing a smooth migration from old installations and extensions. Let's not frustrate them too much in the tedious job of getting the installations up to date.

On this matter we decided that it would we good to bring back the "int_to_ver" method, as this seem to be the top "Fatal error" when upgrading to "master" lately and it's difficult to get a fallback solution for it (removed in #44763).

GIT / Working mode and Submodules

I asked the team how "bigger projects" should work before the phase of sending review requests to the Core. Christian suggested to use github.com as a platform of forking from the official mirror https://github.com/TYPO3/TYPO3v4-Core. This is also how Christian works on his Catharsis fork.

Next Meeting

Next week we won't meet due to me being away for some days (from Thursday to Sunday). So next meeting is on June, 6th.

Keep up the good work and have a great time! Thanks for reading and your interest!

Cheers,
Ernesto

TYPO3 CMS 6.2 LTS Kick-Off and first meeting (93 comments)

Added by Ernesto Baschny over 6 years ago

Instead of simply publishing our "Meeting Minutes" as usual, I decided to take a more "blogging approach", because the scope of information is broader than simply what we discuss in our meetings. It's probably also more fun to read it in this format. If you like it, I would like to keep it during the 6.2 development phase.

First Release Team Meeting

Anyway, the Release Team (consisting of the former Release Managers, the TYPO3 CMS Team Leader and Co-Leaders and the Community Manager - ben) decided to meet every Thursday at 2 PM CET via Skype. So today we had our first meeting.

Participants

  • Oliver Hader (Team Leader)
  • Helmut Hummel (Release Manager 6.0)
  • Christian Kuhn (Q&A, Coder, Co-Release Manager 6.0)
  • Ernesto Baschny (Release Manager 4.5 + 6.2)

Kick-Off Article

I briefly presented the Kick-Off article draft and explained it a bit. Everybody was happy with it, so I published it later on after some final tweaks.

Read it here: 6.2 Kick-Off announcement

It was spread over Twitter and Facebook and the general response is overwhelmingly positive.

Release Plan

The proposed Release Plan was discussed. We reminded that we strive for "April/October" releases. 6.0 was postponed by one month (end of November). 6.1 was "in time" (end of april). I explained the calculated Release Plan:

New Features Phase: 01.05.2013 – 02.08.2013 (4 months)

  • alpha1: 04.06.2013
  • alpha2: 06.07.2013 (Saturday, during T3DD13)
  • alpha3: 06.08.2013

Feature Freeze Phase: 03.09.2013 – 05.11.2013 (2 months)

  • beta1: 03.09.2013
  • beta2: 01.10.2013
  • RC: 22.10.2013
  • Release: 29.10.2013 (planned during T3CON Europe)

The "Release during T3CON" would a cool thing, but this requires the release date not to be postponed. It would also coincide with my birthday (what a present...).

It was agreed that postponing late is not good, so we will keep this schedule for now, and decide upon potential postponements at most on feature freeze time.

For the T3DD we have already handed in a Workshop (already accepted) for working on "6.2" which should end with a "Live Release of alpha2" during (or at the end of) the session. Will probably be lots of fun and maybe attract more potential contributors.

Planned next steps

We decided that Christian should get a new headset due to constant noise on his line. He agreed and will even go so far as to sponsor this asset himself (or his company e-net?). We're looking forward to it! :)

I plan now to get an overview of what's being done and who is doing what. This means contacting contributors, teams and getting more involved.

We also need to check out the Calendar for potential Code Sprints and the need to plan more of them. This will be one task for me in the next weeks.

One particular Code Sprint is already being planned, on the topic of "Workspaces" (also in Extbase). Refer to this doodle schedule for more infos. Thanks for dkd for sponsoring that!

Regressions in stable releases

We discussed the regressions found in stable releases, most prominently:

  • Extbase
  • Mime-Type Function call (PHP 5.2 issue with TYPO3 4.5)
  • Scheduler
  • DBAL

For all of these we have working patches (DBAL requires some more reviews) so that we plan to release new stable patchlevel versions on next Tuesday (May, 21st).

Next Meeting

Next meeting will most probably be on May 23th, but it might get shifted due to my own schedule (which was done before).

Personal Roadmaps

First step for me is to figure out what every individual active contributor has in his head. Everybody working on TYPO3 CMS development has his "personal roadmap" (or vision). In this particular phase on the road to the next release it is my job to "get everybody's roadmap in sync" and to put the focus on the roadmap for people that haven't got a roadmap themselves. :)

This is not an easy task, but inevitable in an open source project. In order to be able to do this, I need to inspire people to go more public with their "internal roadmaps". Share code, share ideas, brainstorm in public, participate in meetings, organize the workload to be able to split it up on more shoulders. We need less "lone wolves" but more group work.

So I started by contacting the initiative leaders with some questions to later further refine the "common roadmap" and bring the right persons together.

Usability Team

One challenge will be the Usability team and interaction between the Core Team and this team. There have been some communication issues in the past, but nevertheless we'll have to work together to get this working. The input from the design and usability experts (Lars and Jens) is very important and considered by our fellow developers.

We have Felix Kopp as a very good peer to the Usability Team. I'll try to get in touch with Lars/Jens soon in order to get the cooperation rolling again.

Documentation Team

I attended to the Documentation Team meeting which took place tonight with Francois and Martin. It was my first participation, and allowed me to get a better overview on that front, which will be very important on the road to 6.2 LTS. We'll get to hear more from the team and the plans during the T3DD in Hamburg: Stay tuned!

Refreshing old contacts

I have also tried to contact some "long lost souls" from the Core Team. People that worked hard on previous releases (in particular on 4.5 which I remember so well, refer to my thank you article from that time). Some are gone for so long, and I wonder why. Maybe we can reactivate some of these talented guys again.

Final words

That's it for today, hope you enjoy the read. Will report back when there is more to report.

Now go fix a bug or review a pending patch!

    (1-7/7)

    Also available in: Atom