Calypso is integral part of Pharo as Iceberg. We started to discuss the problem in the team. Right now this project spread kills us.
Stef On Mon, Nov 5, 2018 at 11:56 AM Stephan Eggermont <[email protected]> wrote: > > Tim Mackinnon <[email protected]> wrote: > > > > > In retrospect, I’m wondering if successful projects that have proved > > integration usefulness should be moved into the core repo? > > (Iceberg/Calypso?) or are we missing something to help easily track the > > journey of a multi faceted change (although this sounds overkill?). Or > > are there sprint days to try and knock these things through easily with > > everyone on board to do it together? > > > > We are sort of damned if you do and damned if you don’t. But certainly we > > want to endure that progress can be made without losing the will to > > contribute. > > > > Indeed. Putting things in one repo cannot scale and cannot be a solution > for something that is neither core pharo nor an application. I encourage > everyone who wants to get a good description of this problem to read > > "Managing Design Data: The Five Dimensions of CAD Frameworks, Configuration > Management, and Product Data Management" by Peter van den Hamer & Kees > Lepoeter. > > With git and github a solution to decouple fast-moving from slow-moving > projects seems to be indeed to fork and make PRs. > That only works if the quality of the PRs is high enough and we manage to > use the feedback from slower-moving projects well. > > Earlier, we’ve seen projects like Magma being overwhelmed by the number of > needed changes, and Pier being broken by Pillar not respecting its > constraints. > > With tools like Travis, it is quickly clear if a PR would result in a green > build in the original repo. > > With projects where Pharo uses only the core, and applications use more > than that, the applications still have a dependency problem: if the core > changes in Pharo influence the other parts, someone needs to do the work to > make those parts work again. With forked repos, that can be a pharo > maintainer, the project maintainer or the application maintainer. All three > need to be able to make those changes. And they need to be decoupled from > having to make them immediately. And being able to have the discussion > about the exact implementation independently from implementing a stop-gap > solution now is also valuable. > > So if Calypso is supposed to be extendable and only the core part is part > of Pharo, having it as an external project makes sense. With a fork for > Pharo to move at its own speed. If Iceberg is Pharo-only, just having > different branches for different Pharo versions, it sounds to me like it > might be better of in the Pharo project. Tonel is supposed to be > cross-platform so should be separate. > > Is this helpful? > > Stephan > > >
