[Pharo-project] moved repos to gemstone
If the corresponding project admins would agree it would be cool to move the development to ss3 on gemstone of the following projects I ported so far: - Citezen http://ss3.gemstone.com/ss/citezen - FSFilesystem http://ss3.gemstone.com/ss/fs - FSGit http://ss3.gemstone.com/ss/fs-git - PetitMarkdown http://www.squeaksource.com/PetitMarkdown - PharoRB http://ss3.gemstone.com/ss/rb-pharo - Refactoring Engine http://ss3.gemstone.com/ss/rb - Soup http://ss3.gemstone.com/ss/soup - XMLSupport http://ss3.gemstone.com/ss/xmlsupport I tried to add people from the old projects as admins Please let me know
Regarding the refactoring engine: I will continue to maintain the code in the spirit of the original authors in my own repository. Of course Pharo is free to fork any open-souce repository, but then the maintainers should not complain if they end up with outdated and broken code nobody has time to maintain (as it recently happend with the one-click builder). Furthermore, it would be appreciated if the projects were renamed and and would use a different namespace. For example, I cannot load any package that depends on the official version of FS. A quick comparison shows that the Pharo fork is based on outdated code and has some methods of the public API renamed. Lukas On Wednesday, February 15, 2012, Camillo Bruni <camillobruni@gmail.com> wrote:
If the corresponding project admins would agree it would be cool to move the development to ss3 on gemstone of the following projects I ported so far:
- Citezen http://ss3.gemstone.com/ss/citezen - FSFilesystem http://ss3.gemstone.com/ss/fs - FSGit http://ss3.gemstone.com/ss/fs-git - PetitMarkdown http://www.squeaksource.com/PetitMarkdown - PharoRB http://ss3.gemstone.com/ss/rb-pharo - Refactoring Engine http://ss3.gemstone.com/ss/rb - Soup http://ss3.gemstone.com/ss/soup - XMLSupport http://ss3.gemstone.com/ss/xmlsupport
I tried to add people from the old projects as admins Please let me know
-- Lukas Renggli (mobile) http://www.lukas-renggli.ch
On 2012-02-15, at 17:09, Lukas Renggli wrote:
Regarding the refactoring engine: I will continue to maintain the code in the spirit of the original authors in my own repository.
Of course Pharo is free to fork any open-souce repository, but then the maintainers should not complain if they end up with outdated and broken code nobody has time to maintain (as it recently happend with the one-click builder).
well the one click thingy should just be a jenkins job on our build server, that would be fine.
Furthermore, it would be appreciated if the projects were renamed and and would use a different namespace. For example, I cannot load any package that depends on the official version of FS.
bah, basically this shows that squeaksources sucks at comunity based multi version code :D to bad that we're not yet on github for that reason... I don't feel like changing the namespaces either since that makes including updates and changes even harder...
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.
Lukas
On Wednesday, February 15, 2012, Camillo Bruni <camillobruni@gmail.com> wrote:
If the corresponding project admins would agree it would be cool to move the development to ss3 on gemstone of the following projects I ported so far:
- Citezen http://ss3.gemstone.com/ss/citezen - FSFilesystem http://ss3.gemstone.com/ss/fs - FSGit http://ss3.gemstone.com/ss/fs-git - PetitMarkdown http://www.squeaksource.com/PetitMarkdown - PharoRB http://ss3.gemstone.com/ss/rb-pharo - Refactoring Engine http://ss3.gemstone.com/ss/rb - Soup http://ss3.gemstone.com/ss/soup - XMLSupport http://ss3.gemstone.com/ss/xmlsupport
I tried to add people from the old projects as admins Please let me know
-- Lukas Renggli (mobile) http://www.lukas-renggli.ch
Regarding the refactoring engine: I will continue to maintain the code in the spirit of the original authors in my own repository.
Of course Pharo is free to fork any open-souce repository, but then the maintainers should not complain if they end up with outdated and broken code nobody has time to maintain (as it recently happend with the one-click builder).
well the one click thingy should just be a jenkins job on our build server, that would be fine.
Furthermore, it would be appreciated if the projects were renamed and and would use a different namespace. For example, I cannot load any package that depends on the official version of FS.
where is such a version?
bah, basically this shows that squeaksources sucks at comunity based multi version code :D
to bad that we're not yet on github for that reason...
I don't feel like changing the namespaces either since that makes including updates and changes even harder...
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. I remember doing it on purpose to share our changes. I remember also having lost the comments I added to some methods and classes⦠apparently comments have no value in our world. So I reentered them. Now if colin does not care about we are doing I have no problem with that. 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. Stef
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
On 15 Feb 2012, at 18:52, Lukas Renggli wrote:
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. I don't know enough about the history of all this, but I completely fail to understand how someone who wrote something like FileSystem or RB would not find it interesting that his code would be included by default in Pharo (and thus support a mutual cooperation). 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. Anyway, that is my opinion. Sven
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.
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.
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
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"
On 15 Feb 2012, at 17:16, Camillo Bruni wrote:
bah, basically this shows that squeaksources sucks at comunity based multi version code :D
No it does not ;-) Monticello does not care where versions are stored, you could ship .mcz files around on an USB stick. The point is, distributed version control is possible, but requires cooperation: if I as maintainer of Zn do not accept your patches no cooperation will happen, it is as simple as that. It requires effort on both sides. This is not a technical problem (although improvements are most welcome), it is a social one. Sven
participants (6)
-
Camillo Bruni -
Lukas Renggli -
Nicolas Cellier -
Stéphane Ducasse -
Sven Van Caekenberghe -
Tudor Girba