Discussions - Neos Sprint 2015 - Frankfurt

The Neos Project Neos Team
1

Topics discussed during Neos Sprint September 2015 – Frankfurt:

2.1 Release

Participants: Robert, Christian, Rens, Daniel, Aske, Alex, Gerhard, Hans

We came to the conclusion of selecting a couple of features that together make the feature freeze. When those features are finished, no more features will be added and a beta release will be planned. This means that no fixed release date nor feature freeze date will be announced, but following the progress of the selected features will give an idea of when a release is finished.

We decided not to have a single release manager for releases, but rather make it a project for one of the cross-functional teams.

The features will all be projects that are assigned to teams to ensure their finalization.

Features:

  • Workspaces
  • Content security improvements
  • History module polishing

Additional minor features:

  • Integrator improvements
  • Tooltips (UX)
  • Help texts (UX)
  • Performance improvements

We expect those major features to be finished in 6-8 weeks.

Moving the code style to PSR-2

We decided that this change can be done at any time without further constraints. The changes will be on the lowest supported version and be merged upwards.
Karsten creates an epic for moving the core packages in Jira.

Namespace Change

The discussion was about renaming the namespaces from TYPO3\* to Neos\*. The namespace is used in code, configuration, database schema and records and in many other places.

As this is really a big and breaking change, we agreed that we will change the namespace with the next major release. We will gather all tasks that have to be done for the namespace change in the jira ticket https://jira.neos.io/browse/NEOS-1602.

Other things that could be done together with this change could be the renaming of the packages TYPO3CR and TypoScript.

The change of the namespace scheme to PSR-4 could be done at any time and has not to be done together with this change.

2

Hey,

I’d like to participate in the “JS Refactoring” discussion and I guess in the “Search” discussion as well :wink:

All the best,
Sebastian

3

Meeting Notes for “Search” Discussion

Attendants: Johannes Steu, Hans Höchtl, Aske Ertmann, Christian Müller, Sebastian Kurfürst, Dominique Feyer, Daniel Lienert, Markus Goldbeck

Evolving TYPO3CR to contain basic filtering

  • we want to support a default possibility for filtering (based on node properties) and sorting without ElasticSearch or SimpleSearch
    • Aske has suggested to put the Search API in a separate package (TYPO3.TYPO3CR.Search), but make TYPO3CR depend on it for the search APIs.
    • All these packages will be part of the Neos Development Bundle (see below)
    • There should be multiple implementations for this package, a “dumb” one based on MySQL / Postgres (which might be based off SimpleSearch); and a “Full”-Fledged one based on ElasticSearch
    • That means the adapters are the following:
      • “dumb” MySql (NodeBased using Indexing Tables)
      • Elasticsearch
      • SimpleSearch
  • NEXT STEPS
      1. request TYPO3CR.Search queries from people for getting the 80% use cases
      1. MERGE/finalize christophers changes which make cleans up the TYPO3CR NodeData Repository (and Christian also has some changes on the list there?)
      1. create index tables in “Dumb” Search
      1. probably add 1-2 methods to NodeInterface to query nodes
    • Start with implementation in CR (rudimentary)
      • first solid interface
      • querybuilding hidden from the outside
    • 4 (Parallel): Raise Quality for Search packages, by writing behat test for dimensions, workspaces, …
      • Basic idea: have different conformance levels to which implementations can adhere to.

Make Search Packages Official Packages

  • We all agree that searching functionality is vital to the success of a lot of Neos projects.
  • using Node Based CR Search (without ElasticSearch) for simpler Projects. For big projects, people will use ElasticSearch (our assumption)
  • Many people of the team are responsible for the Search packages so far
  • SUGGESTION by all participants: raise quality (by writing tests) and then add these packages to the Neos Development Bundle, effectively making them team-owned packages.
  • For Jira, we propose using an “INCUBATOR” project which should contain packages which we want to become part of the core distributions (Flowpack is already some sort of incubator)
  • -> TYPO3CR.Search will move closer to the core
    • integrate in into the Neos Distribution
    • enhance the quality
    • tests
  • We agree backwards compatibility in the existing search API is crucial; but it might be an option to add a feature flag or so to get “advanced” query results back – in order for a query result to contain aggregations etc.

Search Frontend

  • SearchPlugin becomes Frontend ElasticSearch Plugin
    • will be tailored to ElasticSearch features
    • This package could be taken over by anybody in the community/team who wants to help out; Sebastian would hand over this package (which currently still is at a very rough and prototypical state, anyways)
    • solve rendering stuff
    • integrate complex stuff aggregations
    • aggregations could be configurable with yaml or TypoScript
1 Like
4

Tools & Servers (WIP)</h1
  • we need a centralized monitoring system for the servers and the services provided by them
    • define a guideline of how the alert system would work
  • we need to define the guidelines for granting admin access to certain systems
  • we need to define the maintenance cycle of the services
  • installation instruction for common setups
  • packaging for Ubuntu, Redhat etc

5

JavaScript Refactoring Discussion

See notes at RFC: JS Refactoring Process of Backend – and see the topmost posting in that thread for the updated RFC.

All the best,
Sebastian

6

I love this nice status page: https://cachethq.io/ it’s opensource

7

Activity discussion

8

Budget application discussion