Hi, Here is a summary of what we discussed around Pharo issues. Topics: - The process to get to the mini image - Actionable tasks to improve the current situation - Current architecture - Future architecture Problems: - Building speed - Where do we work: Core or Dev - How to collaborate Actions: - Create the OnPharoHead group on Jenkins The goal is to provide a space in which curated projects (e.g., RB, Moose) are built against the head of Pharo. If the project-specific build gets red, the integrator of the project announces the Pharo core team about the origin of the problems. If the project-specific build gets green, the latest Pharo image is integrated in the official continuous integration - We need to speed up the creation of a dev image (core + decent tools) for core developers. To do this, we need to introduce an incremental job that loads the updates starting from the last https://ci.lille.inria.fr/pharo/view/Pharo%201.4/job/Pharo%201.4/. This will make the load much faster (currently, the official build takes 20+ minutes), as the official one is based on an older seed image. - Grease does not load cleanly in Pharo 1.4 because some methods were integrated already. **Someone** has to create a ConfigurationOfGrease for Pharo 1.3, and a baseline for 1.4. - People seem to believe that Builder is not maintained. Lukas maintains it, but to integrate changes, he needs pull requests on Github. - The work on Filesystem should be synchronized. We need to establish the link with Colin. An email must be sent to him. Camillo can you send him an email? The squeaksource/fs repository contains renamings, that are not necessary. Camillo should get in the loop. - RB and AST are important pieces that should be integrated by one person. Lukas offers to play the integrator role. Note: An integrator is more than a maintainer in that he actively (and positively) works with contributors. To ensure an easier collaboration, RB and AST will get an official inbox repository. Lukas will ensure that the architecture of RB and AST remains clean, that the test coverage improves, as well as that new clients are satisfied. The AST extensions (new variable nodes for self, super, ...) leak semantics into the syntax AST. Furthermore they break rewrite rules, code critics and refactoring. Instead, the AST-Semantics package should be dispatched through (or a similar independent extension package). For the parametrization of the RB environment (related to the remote access), experiments with RB (and possibly other frameworks) should be conducted first. If these experiments prove RB to be the right tool for remote access, the changes can be submitted for inclusion. Doru, Lukas, Stef, Philippe, Fabrizio, Stefan and Jorge