[TYPO3-dev] [TYPO3-v4] Minutes from the extraordinary Release Manager Meeting

[Ernesto Baschny]

Hi,

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":http://forge.typo3.org/projects/typo3v45-projects/wiki/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.


Cheers,
Ernesto

-- 
Ernesto Baschny
Core Developer V4 Team
Release Manager TYPO3 4.5

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