I had a quick look in squeaksource/fs and I just wonder... 1) why some API were renamed from the beginning (onDisk => disk inMemory => memory, basicOpen:writeable => etc...) Where was it discussed? What does it serve? Were a request emitted to FS maintainers? Shouldn't such discussion be public? 2) why do commit messages so rarely reflect the changes really going on inside? Do you think it's FS maintainers job to try understanding the purpose and necessity of your changes? 3) why do some garbage get published in the repository (like method #tt for example)? Do you expect maintainers merging garbage in the history, or just cutting such branches? 4) why haven't wiresong changes ever been merged into the squeaksource/fs fork? Do you consider FS maintainers work as null and void? Or do you expect them to commit their work in squeaksource/fs? Is there a development trunk? 5) shouldn't pharo extensions go into a specific package named FS-PharoExtensions? They can eventually be integrated by the FS maintainers, but I guess they have their own schedule. So that is the clean and well behaved way to dot it. IMO. I don't know were bad communication and bad practice come from, surely a bit from both sides... But I can say that I don't understand the development model at all... Who is responsible of what? What is expected from FS maintainers? What should or shouldn't Pharo developers do? I have the feeling there is no contract at all, just a great deal of autism... Nicolas Le 15 février 2012 21:07, Stéphane Ducasse <stephane.ducasse@inria.fr> a écrit :
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.