Hi Nicolas, During the meeting in Bern (see the mail with summary) we discussed the Filesystem problem, and indeed the problem seems to stem from the misunderstanding of what is the official Filesystem repo - the Pharo team seemed to now know that the wiresong repo is still active. The consensus was that the team should reach out to Colin. Regarding the renames, they were observed by Lukas as well, and it is very likely that they are a mistake and should be reverted. Cheers, Doru On Sun, Feb 19, 2012 at 6:13 PM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
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
-- www.tudorgirba.com "Every thing has its own flow"