Hi Tim,

Yes, there you're experiencing the limits of our current process. We were studying the usage of git subtrees/submodules/subrepos but none of them seem a satisfying solution for what would give us a smooth contribution process.

Now, we can enhance a bit the current status by adding calypso in the list of iceberg projects. I agree with this. Actually putting Pharo and Iceberg itself there is something we started to do slowly. There was this feeling that people would complain "agh but I only want to see my projects not the system ones". What I believe is that we are used to see and change all packages in the system, that's in our "blood" as pharoers. So seeing all loaded projects may confuse a bit newcomers but empower experts too...

Also, to answer your question about compatibility in Pharo6/7, or even different Pharo7 versions, what I'd say is that the best way to do it is to keep backwards compatibility when possible. Instead of removing/renaming classes or methods, deprecate them. I'm aware that this is not always possible, so trust your criteria.

Guille

On Wed, Jun 20, 2018 at 3:45 AM Tim Mackinnon <tim@testit.works> wrote:

Thinking about this more - why doesn��t Calypso appear in iceberg as a separate project alongside iceberg and Pharo?

That��s what��s confusing? And how did it get loaded from it��s git project without it appearing?

Which all makes me think there might need to be an iceberg setting - show/hide system projects so they don��t get in the way of your own projects.

But then if you accidentally save a method in a system class - how are we going to spit it and know?

I hate getting burned when you thought you were on a roll

Tim

Sent from my iPhone

> On 20 Jun 2018, at 02:26, Tim Mackinnon <tim@testit.works> wrote:
>
> Hi - so in trying to improve the sendersof/implementors of - I thought I had nailed it (and got working what I had done in Pharo 6 for Pharo 7) - but when I loaded my commit into a fresh image I realised that none of the (minor) changes I had made to Calypso had been committed.
>
> This is actually quite confusing - and its take me a while to realise that Calypso is a separate project and so when I picked commit on Pharo - this won��t pick up any of the changes in Calypso��. Arrrgggg
>
> So now I��m guessing that I have to follow the same steps that I followed for loading a pharo repo - for Calypso?
>
> But then if I do this - and I propose some fixes to Calypso - how can it work, as it relies on some changes to older pharo core editors that its inserting from?
>
> My changes without Calypso will work (they did in V6) - but then how can someone test those in V7 as Calypso is then the default variable.
>
> I��m in a bit of a twist - how can I proceed?
>
> I��d really like to help improve the situation - as its bugged me for years that its a pain looking stuff up quickly (requiring you to highlight just the right stuff for very obvious things)
>
> Tim

��	Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - http://www.cnrs.fr Web: http://guillep.github.io Phone: +33 06 52 70 66 13