I just checked how hard it would be to merge wiresong FS into Pharo 1.4 And I noticed that a few references to Incomplete exception leaked out of Xtreams in the wiresong version and I think that it is a bug... (at least, from Pharo POV). We can all understand Lukas, any change of API will be a hurdle for applications and should be avoided as much as possible. Forking the implementation because the package authority cannot offer support for latest Pharo version is not a problem. But, from above POV, forking the API tests is THE BAD practice. That's why new features along with their test should be placed in proper FS-PharoExtensions, at least until eventually integrated in trunk by package authority. Forking the API is not a problem as long as resources meet ambitions. If not, maybe the efficiency of collaboration is worth a few compromises... Nicolas Le 15 février 2012 18:52, Lukas Renggli <renggli@gmail.com> 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