Minutes from the extraordinary Release Manager Meeting

These minutes are also posted to the typo3.projects.v4 mailing list. If you want to comment on specific topics, feel free to reply on the list. Thanks for your participation!

January 19th 2011

We today had an exceptional "release manager united" meeting to discuss the current state of affairs of the 4.5 release, considering that we are at the final sprint, shortly before RC1 (release candidate).

Present were Oliver Hader (Core Team Leader and 4.3 Release Manager), Ingo Renner (4.2 Release Manager), Michael Stucki (Core Team Co-Leader), Steffen Kamper (4.5 Technical Leader), Ben van't Ende (Community Manager) and Ernesto Baschny (4.5 Release Manager). Missing were Benni Mack (4.4 Release Manager) and Ingmar Schlecht (4.1 Release Manager).

The goal was to get an overview on open matters, make some decisions and define how to proceed.

General discussion

Olly introduced our meeting with pointing out the concerns raised amongst core developers and active participants of the community before beta4 and now shortly before RC1.

Ernesto shortly summarized the current state. Development rate raised again after the "hole" of Christmas holidays and many things were solved after beta3 and beta4. We don't see any major blockers currently and are happy that many active participants are giving positive feedback and sharing a positive feeling. Ernesto understands that the negative and pessimism is part of the process and has always been like that shortly before a release.

Steffen also commented that we had a hard schedule, especially the last month (after feature freeze) because of the long period of very little activity (due to the holidays).

Regardless of that we managed to stick to our set schedule and won't be postponing the final release. This has never been achieved before and allows the release to get more and focused highlighting than ever. Especially because it will be an LTS (long term support) release, we want to make sure every stable new feature we have is included.

Release Candidate

About the schedule, Ingo shared his reminder that a "release candidate" should be threated as such: It should be considered "ready" (we could "release" it by just renaming it). Ernesto said that this is known by us and we expect the RC1 to be really great, and to be able to finish the tasks we postponed it until Friday (scheduled for Wednesday).

We will observe the fixing and reactions during the weekend after RC1, and on Monday we decide if we want to release an RC2. Ernesto reminded that on 4.4 the final week also went like this (RC1 17.6., RC2 20.6, Final 22.6.) especially because major changes were still done at that phase: We won't have such major changes anymore in 4.5. At the end it turned out very well also for 4.4 and everybody was happy with 4.4.0.

Ernesto also said nothing is never "completely finished". We have had the goal to finish everything in 4.4, but we see that many of the projects from 4.4 were finished just now with 4.5. So we also expect that some projects from 4.5 will be finished on later versions. They still need to be included if they are stable enough and provide a public API which won't change anymore.

We discussed if we want to "lock SVN" after RC1 (Ingo's suggestion) but Ernesto thinks that this might block bug fixing which might happen during the weekend. There will be clear rules after RC1 is released for all core developers but also for externally hosted projects: No commits which are not strictly necessary (bug fixes of proven bugs).

Reviewing

Steffen mentioned that he and Ernesto are working very nicely as a team (this should be repeated on future releases) and they are monitoring everything that is being commited (post-reviews). Which brought Michael in memory that we used to have RSS feeds of SVN commits (it was a feature of Trac, but isn't working with Redmine). Steffen mentioned that this can be done by each own interested party. Ernesto follows the changes in the repository view of Forge. But in future it would be cool to have RSS again.

Projects

We then decided on the major topics to discuss:

  • Plupload
  • Linkvalidator
  • Grid View
  • New Extension Manager

Plupload

It was rised the question why this needs to be further discussed. Ernesto explained that there has been criticism about it entering at a late stage after feature freeze. But in fact this was included in a exception rule we clearly had for the feature freeze (documented on forge): Plupload was a subproject of "FAL" (file abstraction layer) integration, which we decided to drop later on. At least the Plupload integration was easy enough that we could keep it.

The integration suffered because of the lack of an unified API for "file uploads" (which is also part of the FAL project, and thus we don't have it yet), so the Plupload needs to be integrated manually at every location where "files can be uploaded". The current state implements the integration only in the Fileadmin area, which is also the only place the already included Flash-Uploader is integrated.

Steffen mentioned that Plupload works with html5, Flash and "classical HTML4" methods, providing automatic fallbacks. The Silverlight fallback was skipped due to licensing questions. The Uploaded was tested by Olly and he likes it.

Others mentioned that it is confusing to have the uploader configurable. We decided that "at the end" (4.6 or later) there should be only "one uploader" which works in all cases, and not having that configurable per user (and this will probably be Pluploader). Currently this is not possible because every user could have different kinds of troubles with the two enhanced uploaders.

Ingo asked why this is not configurable globally per site, because choosing an uploader is very technical (for each user to decide that). Ernesto agreed, but explained that from user to user the one or the other uploader might work best. This is of course sub-optimal, but at least each user has a choice (depends on browsers, proxies, HTTPs usage, cookies, etc). Ernesto will check out if this default can be configured via userTS.

Steffen said one issue is the missing "Drop zone" label to make it clear that in HTML5 mode files can be dragged into the uploader.

We agreed to make Pluploader the "default uploader" (Ernesto will ask Christian to take a look and make this possible).

Other possibilities mentioned by Ernesto were to remove SWFUpload (since Plupload also contains a Flash fallback). The question was rised about backwards compatibility (it might be used by extensions already), and since we don't have a generic API, its a risk. So we decided to keep it (in 4.5) but try to add a deprecationLog() message when it is being accessed.

Then in 4.6 we have enough experience with Plupload to maybe get rid of any other way of uploading files to TYPO3 (and get rid of the setting).

Grid view

Ingo mentioned that more reviews for this code is needed. Documentation is also not ready. Ben contacted Joey about it and currently he is waiting for the user interface to stabilize (to be able to make the right screenshots). Since this should be the case after RC1, the screens can be done during the weekend.

Ingo told us it works perfectly, the functionality is very good. He will do a code review later on (CGL, naming). One thing would be to rename the DB table from plural (be_layouts) to singular (be_layout). Ingo will do a patch for this, there is already an issue on Mantis. Ernesto asked why is this so, because other be_* tables are plural. He said this is the best practice he learned from DB books. Ernesto said that different frameworks do it differently and that we don't have a rule in our CGL yet. Singular seems to fit (because FLOW3 / Extbase use it), so we will have to make sure to add it to the CGL (and start using the singular variant for new tables, even if it doesn't fit the "old wrong names").

The Forge issue tracker for "modernbe" is obsolete. We need to close it (and move the pending issues to mantis). Olly will coordinate with Joey. The Pagetree issue tracker is already closed. Steffen reminded Olly to also change the start page of bugs.typo3.org to reflect that changes.

Linkvalidator

Also for the linkvalidator we need to change the table name from plural to singular to be in line with the above decision, Ingo noted. This brought us to this next topic.

Olly did some testing and wrote an review yesterday. Ernesto already is in contact with Patrick about the current concerns. Olly said about the code quality that it looks good but there is still room for improvement. Lots of activity happened during the last weeks, and the team is still very motivated.

Steffen mentioned that some issues encountered were bugs with "refindex". Going to DB Tools > Update refindex solved most of them.

He also said about the missing support for "redirect URLs" (if the URL is a redirect, its sometimes detected as a failure). Ernesto explained that this is not Linkvalidator's fault, but the lack of a better API to check for URLs in TYPO3. Linkvalidator uses t3lib_div::getURL, which has three different ways of checking URLs depending on system configurations: cURL, fsockopen and file_get_contents(). And these also behave differently depending on system (Windows / Linux / Mac). Most reliable option is to use cURL (curlUse=1 in Install Tool), but this presents some problems in certain situations (e.g. https links with might get failures because the server where TYPO3 is running might not have the same root-CAs available to validate it: and getURL doesn't provide a way to tell curl to ignore invalid SSL-Certificates, etc). So at the end, we would need a much more stable API for fetching URLs, which is long overdue, but was not in the scope of the Linkvalidator project.

Ingo said that during his review he filled 3 sheet of notes, basically with "small stuff". We went over the notes, some were explaineable and some should be fixed still. Ingo will report the issues through the tracker later on. One of them being "Christopher" to sign his changes with a full name. :)

We looked at the user interface and Olly and Ingo were confused about "two buttons" (Refresh / Check). We thought it might be best to just remove the "Refresh display", as it is pretty useless (and confusing).

Ernesto also explained his communication with Patrick, which was frustrated by getting these reviews only at this late stage. Christian Kuhn (core developer) is also part of the team, but was not active on it for a longer period. Patrick explained that every issue is being worked on and it would have helped to get these comments earlier on.

We at the end decided to keep it in core for 4.5, with the pre-condition that last pending issues are fixed (email checking bug, CGL, naming, etc). So it will ship with 4.5.0 RC1 and also the final release.

After the release we need to have a continuous maintainace, Ernesto said Patrick already committed to keep on working on it with his team.

Criteria for new sysext

We came up then with the need to set up some criterias for an extension become a "system extension".

We have had in the past the idea of "A-Class Extensions", which we were not able to agree upon until now (everyone has different ideas of what that would mean). Linkvalidator (also FE-Edit-Advanced) would be perfect candidates for that. Since we don't have "A-Class" extensions, we went over basic rules for new sysext:

  • One of the team leaders of a sysext needs to be a Core Developer. This is important to have a core developer as a central hub for issues concerning the extensions, needs to make sure the code quality is up to the core's standards, and do the actual "merge into trunk" before the releases.
  • It has to be developed as a "team". The list of active members (on forge) have to reflect the current activity.
  • The team needs to have a working reviewing system (4-eyes principle), might be similar to the +1 system of the core list.

For Linkvalidator this means: After 4.5.0 release the team has to consider the roles of their members, kick inactive ones and declare a stable leadership (with one core leader being part of it).

New Extension Manager

Steffen reported that its mostly done, many issues have been reported only on the last two weeks, so the schedule is very tight. Steffen is working almost alone on that because noone volunteered to help.

Olly did a large review lately with screens and comments. Steffen will go through it manually with Olly after our meeting (http://forge.typo3.org/issues/12195). Main problem for Steffen is that its a "real monster", because the old EM code was refactored and its not always easy to understand.

There was a complaint from Dmitry (via Facebook) about having a list of updateable extensions. Currently its in "Remote extensions" tab as a "Filter". Missing is the changelog and the "overview" to quickly be able to update more extensions at once. So we decided to have the old "Check for updates" module back in the top selection bar.

The old modules are still implemented and working, they are just not linked in the function menu. The "EM" Extension (search for "Manager" in the Local list) has a Configuration option to "Show old modules". Stucki mentioned the problem of the default value of this setting is "ON", while it is only activated once the configuration is "Saved" on that screen. Since the EM is Required, no one manually installs it, thus never goes to this screen. A solution would be to check if the value is set at all, and if not => Assume the default.

Ingo thinks that it has some nice features and is technologically great, but feels that it makes some operations worse. He doesn't like the ExtJS grids in general, because they take up space, don't have the same feeling as a regular webspace (where you can scroll at will).

The file editing is very cool, but inside that tiny tab its too small, should always be a "new window" (there is an icon to open a new window with the current file editor).

Also the expansion inside the grid was criticized by some, as not being usable. One use case Steffen mentioned was that one can switch tabs, and the extension is still "open" in the grid. Criticism from the usability point of view were that the grid then has multiple Tabs inside Tabs and the content area gets very small (e.g. on Mac you never work with "full screen"). Also it was easy to "loose" the open extension in the list and keep scrolling to find the information that was just opened. Steffen said that the preferred way of using this tool is to use the "Search" instead of Scrolling. In later trunk versions it even auto-completes the grid while typing. So searching for "Manager" gets you quickly the EM.

There is an option in the EM to enable popup windows instead of row-expander to open the information. After some debate most (Olly, Ingo at least) preferred to have this popup window view of extension details as the default.

Ingo also noticed some ExtJS errors (http://forge.typo3.org/issues/12214) which have been reported by others. Steffen was not able to reproduce it, so he is not able to fix it. Even on Ingo's installation he hasn't got that problem.

We all agreed that we will keep the New EM inside the core for 4.5. The open issues are mainly usability issues, the functionality is working nicely.

Stucki suggested not to make the current state the "default", but keep the old one and have the option to use the new EM if desired. Maybe re-enable it as default 4.5.1 or 4.5.2 when the interface gets more stable. Olly and Ingo seemed to agree with that. Ernesto mentioned that this is probably only a "problem" for upgraders which are not used to the new EM and suggested to have an Upgrade Wizard to let the user choose, and still have the new EM as the "default" for new installations. And then have a clear and documented switches (in the EM Configuration to "Show old modules" or "Show new EM" to let the user choose the default on their own.

Ingo will further review the EM and post the results to the tracker.

Documentation

We also mentioned that the teams are already working on documentations:

  • Workspace team (Susanne)
  • Pagetree / Context menu (Peter Galinski)
  • Grid view (Joey)

Most documentation effort was waiting for a stabilized backend design, since some details have changed after the "feature freeze". Ernesto mentioned that this might need better communication in future releases. But the screenshots done now won't differ so much from the final result, and even if some minor issues are still being fixed, the overall design is ready.

Schedule

On Friday Steffen and Ernesto will meet to release the RC1 late at the afternoon.

On Monday the regular Release Team meeting will collect the last pending issues. Maybe release a RC2, if it fits.

On Wednesday, 26th, is the big day of the final release.

Ben is already preparing together with the Press Team and some Designers lots of cool stuff for the Release (Homepage, Press Articles, etc).

The whole team is very excited about the release and we are sure that everybody will enjoy it!

Thanks for your endurance while reading this long minutes.