Wednesday, September 29 2010
Code Sprint v4 in Stuttgart - 14. to 17. October
* 4 Days Meeting (Thursday - Sunday)
* Infrastructure: local servers, etc.
* currently 6 people agreed to be there
o Ernesto, Ingmar, Benni, Steffen Gebert, Olly, Ben, Jens?, Bastian?
* costs will be covered by core team budget
* will work in Teams
* also relevant for working on Usability Aspects
* Goal: Real Code! Merged into Core! Get Things Done!
* Will be marketed as official meeting
* (Ernesto) Create Wiki page about hotel booking, organization, list of participants ...
* (Jens) Post something to the forge page of the HCI team
* (Ben) Create some Buzz. => Calling by Phone with concrete ideas helps
10:20 Status of BLE Project
* Usability and Accessibility
* Work in Sprints!
has been going on for over a year so far -- quite buerococ
* most difficult was: no legal body which handles the task
* last things: who will have which responsibilities?
* Accessibility: Focus on Frontend!
11:20 Git Experience of FLOW3 Team, Discussion about Git in v4
* Pronounciation: [git], not [chit]
* review.typo3.org / git.typo3.org
* we switched after small testing, but not after large-scale testing
* it has a different mindset, one has to learn the concepts
* Safety Net: gerrit
o every change is pushed to Gerrit, so it can be reviewed
o of 130 changes, we have had about 2-3 mistakes (caught by gerrit)
* Improved Review Intensity / Code Quality!
* One has to login all the time, even for viewing in Gerrit
* Next Steps:
o Personal Sandboxes
* Problems with Git at the Workspace Meeting
o merged trunk without cleaning changes
o took quite a time to fix the issue
* Next Steps for v4:
o Focus on TYPO3 v4 Core!
o Wait after 4.5 is out!
o Please read Git/Gerrit Documentation on Forge and give feedback (to get a feeling):
o Stucki will be the "v4 Git Gatekeeper"
o We need a "Poor Man's Git" Documentation
+ very good tutorials needed
o Task Force for getting Git in Core
+ Karsten: Git Master
+ Stucki: Gatekeeper
+ Andreas Otto
Status of Documentation Project
* Next Documentation which will come out
o Getting Startet Tutorial
o New Skinning API
o 4.4 Updated Docs
* will use new documentation template
o more beautiful, and common general structure
o easier to read (new fonts)
o contains more "meta-information", like that it is Official Documentation, which type of Manual it is, ...
o There are the categories:
+ Core Manual
* Rendering on typo3.org the new template is a new step
* convergence with v5 Documentation
o start with fresh design
o Leaning very strongly to DocBook
* DocBook Collaboration Tool (PHP has developed a collaborative DocBook editor) -> is being looked into right now
o looks extremely promising
o only drawback: quite tied to PHP directory structure right now
o not WYSIWIG
* New Documentation Design
o need a Typographer Designer
o working together with OpenSuse project on Documentation
o François knows people ready to help out
* Protected wiki pages on wiki.typo3.org for documentation
Core Team Mission Statement
The TYPO3 Core Team endeavors to make TYPO3 the best of its breed. To achieve this vision it pursues the following goals:
* maintain and enhance the TYPO3 core
* ensure TYPO3 source code quality
* be a pillar of the community
This translates into the following tasks:
* package and publish new releases according to the release and maintenance policies
* review patches both before and after commits
* (OLD: maintain) care for the central development infrastructure (version control system, bug tracker)
* participate in the mailing lists and in community events, in particular (OLD: organize and drive) the TYPO3 Developer Days (T3DD)
* ensure its own continuity by educating and inspiring community members to participate in the development and maintenance of the core
* Not all members take up all the tasks, but the whole team is responsible for that.
* be open to new ideas from inside and outside of the team, open mindset
* 12:00 Status of documentation (François)
* 12:15 Discuss and finalize the Core Team Mission Statement (François)
* 13:00 Lunch
== LUNCH BREAK ==
v4 meeting only:
BLE project brainstorming
* BITV compliance: A new version of the standard is upcoming (v3): possibly use that already (supposedly it's less strict)
* css_styled_content: Outsourcing hardcoded bits into TS
* FAL (file abstraction layer): approach to have a common way of handling files and add meta information for improving accessibility (title, description, ...)
* List module
o => there was the "sponsored projects" project description for a list module refactoring
+ it is still not implemented, but the ideas are still relevant
+ parts of the project description could be used
o => a google summer of code project was about the list module (Thomas reports)
+ there are some nice littlee features implemented such as an easier selection of columns
+ the code is not very nice, but the functioanlity is fine. Needs refactoring to go into the core.
* Install tool
o install tool should help more in setting up a well-configured installation
o possibility of "pre-configured" installations
o some serious usability issues in the install tool should be fixed (example: admin user creation is in "database analyser", where users wouldn't expect it)
* Flexible content elements
* More flexible concept for content elements (Ingo)
o Concept of content elements, which you can define yourself
o A content type manager should help you define content elements
o Content should be rendered by plain TS (but TS needs to be extended so that there's a way to easily access the relational data)
o Two (independent) foundational parts necessary for this (in addition to the Content Type Manager):
+ TCEForms needs the ability to enable seamless editing of relational content element data, so editors don't feel the difference to how content element editing used to be. This would be similar to the IRRE functioanlity (i.e. inline editing of relational data) but should not look like it. It should look like flat forms to the editor. Only for repetitive data, an interface similar IRRE offers now, could be used (but lets keep this for later; easy stuff first).
# Factors that add complexity to this task (similar problems IRRE has):
* Translation handling
+ Changes to content rendering in the frontend, so that the relational data can easily be accessed from TS (e.g. as a flat array, hiding the underlying relational complexity)
* Frontend Editing
o basic editing works, editing of recors and a number of other issues are still open
* Media Elements
* Indexed Search
o Stucki points out that it's important to have a search running out of the box
o Indexed_search has some implementational flaws, although it is running out of the box
o Stucki reports that Dmitry's plan is to start a new implementation of indexed_search from scratch
o Ingo suggests to build a search API in the TYPO3 Core and ship a default which runs without additional requirements to the environment (Ingo suggests ZEND Lucene as default implementation, which only requires PHP)
o As a starting point, some parts could be extracted from the SOLR extension (Ingo will dive into the possibilities of this)
* Page Tree
o Possibly only lay the basis in 4.5 and use it in SOME places, but not all
o Susanne reports on status: Abstract classes are done, starting implementation of trees. Now tackling context menu, as the way that part was kickstarted at UXW was regarded as not optimal.
o More time and resources are needed for getting this into 4.5; fear of unfinished project.
* Improved Workspaces
o Meeting in Wiesbaden about this
+ Revampign the whole backend module was started
+ ATM you don't see a page tree in the workspace module. This would be changed, so you have a more limited view, concerning only the pages you're interested in
+ Possibility to customize stages. Should be more than just editing, reviewing and publishing; but could be things like Send to translation, or other customized stages.
+ Cleanup of TCEMain from versioning / workspace related stuff, so it is as much as possible encapsulated in the versioning extension.
+ Benni says this part possibly does not need to be a part of BLE, as it's running well stand-alone right now.
* "Governmental Package"
o possibility of creating similar packages like the Introduction Package would be useful
o maybe it could work T3X based instead of SQL based, so it's not as version-dependent and the package can include files
* Better error numbers and pages in the wiki regarding each error
Thursday, September 30 2010
Reviewing the protocol of the last meeting in Elmshorn at T3DD10
just taken the TODOs from there...
* HAS TICKET: Migration from v4 to v5
o TODO: case study: how to port an Extbase extension from v4 to FLOW3 (real plugin)
o Create an article on typo3.org! Benni
* Extbase/Fluid as big features are perceived well
* Create a "Extbase Case Studies" site on typo3.org
o everybody who uses Extbase: please contact Andreas Beutel with some links
o Create an Extbase backend module in 4.5 for the core?
o TODO to Discuss: A-Class-Extensions based on Extbase?
* Collaboration UI team / Core Team
o Documenting the workflow on typo3.org - Jens will do that
* HAS TICKET: We need a tutorial on how to port Extbase extensions to FLOW3
o First thing needed is an extension which qualifies as a good candidate for this.
o Dan Brün is presenting a news extension based on Extbase at T3CON. (Karsten will contact him)
* Tasks need to be followed up after meetings (Olly will take care to transfer them to the bug tracker and follow up on them - check the current protocol for "HAS TICKET" tags to see what has been reported already)
Phoenix / FLOW3 Status
* Robert shows a demo of the current version
o What is still missing? What parts still need major work?
+ Error handling
+ Translation / Localization
+ User Interface
+ Command Line Interface
TYPO3 4.5 Status (Ernesto and Steffen)
* Status: The beginning of the development phase coincided with holidays of a lot of people
* Alpha 1 did contain quite some things already
* Between alpha 1 and 2, not so much happened
* For Alpha 3 and Beta 1, the most active phase can be expected.
* The Code Sprint in Stuttgart is happening right before Alpha 3 release, so work can be done for that there
* Case at hand: extdeveval
o There is no main developer at the moment, it's hard / impossible to make changes
o Should be in SVN and core developers should have access to it
* Old ECT: Is it dead?
o Yes, it is not active any more.
o Problem was that it doesn't communicate enough, which is central for a coordination team.
o TODO: Stucki shuts down ECT list and publishes an announcement about it
o TODO: Stucki and Steffen sit together and write an announcement text about the ECT shutdown
o Shutting down lib/div as well.
o Tasks (Stucki):
+ remove page on typo3.org from official website
+ write text for news.typo3.org
* A lot of questions are raised:
o Should de-facto standard extensions like realurl, templavoila, or also sysexts be developed jointly. Should there be teams for all of those extensions? Or one team caring for all of them?
o A-Class extensions: What about the idea of requiring a-class FE extensions to use extbase?
* Extension Coordination Team
o Goal would be to coordinate between extension development teams.
o TODO: Define policy for extension key transfer (Steffen guides / drives the process)
* Development vs. Coordination
o The ECT team should not be responsible for *development* of extensions, but about coordinating the development
o Idea: Building blocks should be re-used within a-class extensions
* At Developer Days: Discussion about what tasks make sense for a-class extensions
o Developing extbase based extensions from scratch would be hard
o Most important things are generic domain models (Ernesto has notes from the meeting with list of imoprtant generic models)
Discussion from the T3DD10:
* building block, generic domain models for:
* - categories
* - person (vCard), organisation, names .. => Jochen 80% done (like the "party framework") => https://forge.typo3.org/projects/show/extension-generic
* - account => stripped down fe_user
* - date, daterange
* - event (iCal)
* - recurrence rule
* - product, catalog, ... (BME)
* - resources (files, media..)
* - ...
* news / shop / etc needs a generic base (should be in core):
* - record listing
* - single view
* - ..
* - requires "account"
* fe_userregister => User Registration
* - requires "account" + "party"
* - requires "party"
* Group 1:
* - Steffen, Andi, Stucki, Christian, Thorsten, Ingo
* - account model: username + password ( with or without "party" )
* - issue might be user_groups
* - mapping of existing data (fe_user)
* Group 2:
* - Jochen, Karsten, Xavier, Bastian
* - party (person, organisation, ..)
* Group 3:
* - Susanne, Andreas, Andreas, Stefan, Ernesto
* - generic display of "records" (list, single, ..)
* Extension Coordination Team should take care about these components and ensure that they are maintained, used, etc.
* A-Class extensions should be based on those generic models
* Which other extensions should be allowed to carry the label A-Class extension?
* Jochen: Find low-entry point that is doable in the afternoon. Start thinking about extensions and what generic models are needed in there, so work from the concrete to the abstract.
* What are A-Class extensions?
o Extbase based extensions only?
o Maintained by us?
o Everything that is used on most TYPO3 websites (realurl, templavoila, sr_feuser_register, tt_news)?
o What to do with kickstarter and extdeveval? Who maintains them?
* How can we maintain the quality of A Class extensions?
o Ingo: Idea of an incubator
+ team that helps integration and makes sure that the official concepts are used, the project "culture" is maintained etc.
o Do we want extensions like tt_news to qualify to being a-class extensions?
o Ingo: Proposes to change the name to something different than a-class extensions
o Preconditions for becoming A-Class extensions (for entering the incubator stage)
+ Minimum quality standards
+ General use case extensions only (not specific functionality)
+ only one extension for one functionality
+ Extbase should be a requirement (only) for those extensions, where it is useful (such as FE plugins)
+ CGL has to be respected
+ Meaningful extension keys (could also be given to the extensions by us during inclusion)
+ Follows security guidelines
o Rules that should be imposed on a-class extension projects:
+ No one-man show (Forge project, SVN usage, issue tracker)
+ Release policy according to TYPO3 way: Breaking changes only with major versions, only bugfixes in patch level versions
+ Review process to handle contributer's patches
o Status of an extension as "a class" can be taken away (e.g. if they are superseded by better extensions)
o Benefits of making an extension an A-Class extension
+ More exposure
o Goals of A class extensions
+ The idea started off with: Which extensions should 5.0 have, when we call it "final"? What are the important extensions?
+ Guiding users in the jungle of extensions to what are the important ones
+ Serve as examples for good extension development
+ Code Quality
+ Recommended (often used)
o We should have an application form.
o Note: The aim is not for extensions to go into the core, but to get the label of being of high-quality ("a class extension")
Maintenance of certain extensions
* Realurl etc.
Maintenance of v4 system extensions
* Ingo asks for a simplified review process for modifications in the reports module and feels himself responsible for reviewing RFCs contributed by others (since he is the maintainer of that particular project)
* List of extensions that have a special commit policy - who's responsible
o dbal: Xavier
o rtehtmlarea: Stanislas
o t3editor: Tobias
o reports: Ingo
o scheduler: François
o extbase/fluid: Extbase Team (Sebastian & Jochen)
o felogin: Steffen Kamper
o version: will be extracted to be an external project later on (when the BE module is ready and extracting functionality from TCEmain is finished)
o feedit: Jeff
Hands on sessions TYPO3 4.5
List of projects that we are going to work on during the next few hours:
* ExtJS Page Tree: Steffen Ritter, Stefan Galinski, Susanne Moog, Steffen Kamper
* TCE Forms Refactoring: Andreas Wolf, Olly Hader
* UTF-8: Michael Stucki, Benni Mack
* Reviewing RFCs: the rest