A quick comparison shows that the Pharo fork is based on outdated code and has some methods of the public API renamed.
where's the other code located? I would like to check that.
Me too especially because I committed in FS on squeak source and not in Pharo so that colin can commit. Because originally I worked on PharoTaskForces.
This is not how open-source works [1, 2]. Not even Pharo works like this.
In addition I do not see how we can control our life if we cannot publish on the repository of a part that should be central to us.
I understand that you want to change things. Also I understand that the original project might be too slow, or that the authors might not accept your changes. In this case it is only fair to do a proper fork [3], to choose a new name, and a new namespace. And to live with all the consequences.
Lukas
[1] http://producingoss.com/en/getting-started.html#developer-guidelines [2] http://subversion.apache.org/docs/community-guide/general.html [3] http://producingoss.com/en/forks.html#forks-initiating
-- Lukas Renggli www.lukas-renggli.ch
Cooperation has to be mutual.
This is what I thought too but I'm naive.
I don't know enough about the history of all this, but I completely fail to understand how someone who wrote something like FileSystem
I started to really want to use FS so I started to comment it and publish my change in PharoTaskForces and people told me that I should share so did I and I put a FS project on Squeaksource and colin pubslihed one version there. thought that he would continue to publish there but not. This is ok. Now let us be free. I do not think that it makes sense to continue like that.
or RB would not find it interesting that his code would be included by default in Pharo (and thus support a mutual cooperation).
Because we want to change some of the approach to be able to manage remote refactorings and this goes against the Design of RB but with bit of discussions and positive energy if would be probably easy to get somewhere. Now we will see and probably have to fork. When people do not want to collaborate then you work on your own. We arrived to the point that for example for SmallLint we will have to fork everything because we do not dare to propose extensions. And to collaborate you should trust people and there is not even an inbox in SmallLint and other projects. So this measn that changes are not welcomed. This is ok too but this is another approach. Simple. This is just sad to see a microscopic world with nearly no impact on industry struggling instead of pushing in the same direction. Anyway we will do it. Because Pharo deserves better vision than that.
Being in an image by default means much more usage and true OSS feedback, it will only improve things.
We have to work together to make progress.
Not necessarily ... Stef
Anyway, that is my opinion.