[Pharo-project] Submitting changes to upstream repositories
Hi, There are recent versions of VB-Regex in the images, but they are not at http://www.squeaksource.com/Regex I will copy them but that's just on of those things that make people say Pharo is not playing nice with other forks⦠-- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
Hi damien On May 9, 2009, at 3:09 PM, Damien Pollet wrote:
Hi,
There are recent versions of VB-Regex in the images, but they are not at http://www.squeaksource.com/Regex
which images?
I will copy them but that's just on of those things that make people say Pharo is not playing nice with other forksâ¦
we consider Regex are part of the core of pharo so what would be the solution?
-- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Sat, May 9, 2009 at 18:05, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
There are recent versions of VB-Regex in the images, but they are not at http://www.squeaksource.com/Regex
which images?
Recent Pharo-cores
I will copy them but that's just on of those things that make people say Pharo is not playing nice with other forksâ¦
we consider Regex are part of the core of pharo so what would be the solution?
Depends what you mean by "part of the core". If it's "included by default", then submit the fixes back to the original project then copy the mcz in the pharo repository if it's practical. If it means "part of the fork", then you take responsibility for maintaining your versions, but I don't see the point since it's code that is quite platform-agnostic, and still it would be nice to notify the original project (i know, it's not possible with squeaksource). Maybe a feature request for SourceTalk, keeping track of branches across repositories. -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
I agree with you Damien. We should not take this dangerous path. If Pharo enhances a package picked from somewhere else, the enhancement must be push back from where it come from. Alexandre On 9 May 2009, at 18:32, Damien Pollet wrote:
On Sat, May 9, 2009 at 18:05, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
There are recent versions of VB-Regex in the images, but they are not at http://www.squeaksource.com/Regex
which images?
Recent Pharo-cores
I will copy them but that's just on of those things that make people say Pharo is not playing nice with other forksâ¦
we consider Regex are part of the core of pharo so what would be the solution?
Depends what you mean by "part of the core".
If it's "included by default", then submit the fixes back to the original project then copy the mcz in the pharo repository if it's practical.
If it means "part of the fork", then you take responsibility for maintaining your versions, but I don't see the point since it's code that is quite platform-agnostic, and still it would be nice to notify the original project (i know, it's not possible with squeaksource). Maybe a feature request for SourceTalk, keeping track of branches across repositories.
-- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On May 9, 2009, at 6:36 PM, Alexandre Bergel wrote:
I agree with you Damien. We should not take this dangerous path. If Pharo enhances a package picked from somewhere else, the enhancement must be push back from where it come from.
Come on this is only possible if the changes you do don't break on other code. else people will start to complain that we are polluting the repository with pharo specific version. So either you take the time and check that this is ok (have the rights to publish, and that the version does not break on Etoy, Squeak3.8, 3.9, 3.10, croquet) and we can publish the code there. Or we don't. Now there is the HUGE question of ressources. I think that pharo is making progress and this comes at a certain prices. as we say: on ne fait pas d'omelette sans cassser d'oeuf because this applies also to SUnit and others. Stef
Alexandre
On 9 May 2009, at 18:32, Damien Pollet wrote:
On Sat, May 9, 2009 at 18:05, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
There are recent versions of VB-Regex in the images, but they are not at http://www.squeaksource.com/Regex
which images?
Recent Pharo-cores
I will copy them but that's just on of those things that make people say Pharo is not playing nice with other forksâ¦
we consider Regex are part of the core of pharo so what would be the solution?
Depends what you mean by "part of the core".
If it's "included by default", then submit the fixes back to the original project then copy the mcz in the pharo repository if it's practical.
If it means "part of the fork", then you take responsibility for maintaining your versions, but I don't see the point since it's code that is quite platform-agnostic, and still it would be nice to notify the original project (i know, it's not possible with squeaksource). Maybe a feature request for SourceTalk, keeping track of branches across repositories.
-- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Sat, May 9, 2009 at 18:59, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Come on this is only possible if the changes you do don't break on other code. else people will start to complain that we are polluting the repository with pharo specific version.
Maybe, but I don't think so, provided it's clear the snapshots come from pharo. Sure, it would be easier if MC and Squeaksource supported branches, but⦠I'm just asking for some communication on what you fork, not for backporting everything to Squeak. I think at least the minimum would be to edit the project descriptions to indicate that they have a pharo branch and where to look for it. Another solution, for a small package like regex, would be to just mark the latest not-pharo version, and take ownership of the project. After all, the only non-pharo guy there is Avi. -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
On May 9, 2009, at 7:42 PM, Damien Pollet wrote:
On Sat, May 9, 2009 at 18:59, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Come on this is only possible if the changes you do don't break on other code. else people will start to complain that we are polluting the repository with pharo specific version.
Maybe, but I don't think so, provided it's clear the snapshots come from pharo. Sure, it would be easier if MC and Squeaksource supported branches, butâ¦
OK I understand.
I'm just asking for some communication on what you fork, not for backporting everything to Squeak. I think at least the minimum would be to edit the project descriptions to indicate that they have a pharo branch and where to look for it.
Yes please do it since you are an admin
Another solution, for a small package like regex, would be to just mark the latest not-pharo version, and take ownership of the project.
I would prefer to make sure that people understand that they can use it and get a working version for their environment. So if you can publish a more recent version there and make sure that this is clear that this is working on pharo. This would be good.
After all, the only non-pharo guy there is Avi.
-- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
from pharo. Sure, it would be easier if MC and Squeaksource supported branches, butâ¦
The central concept of MC *is* branching and merging. In fact, with every commit you create a branch. I guess you are talking about named branches. This was broken for a while as people used dots in their initials, but Julien and I provided patches that are included in recent versions of Pharo. We use named-branches in Seaside and in various commercial projects extensively.
Another solution, for a small package like regex, would be to just mark the latest not-pharo version, and take ownership of the project. After all, the only non-pharo guy there is Avi.
My take on this is the following: If you fork you create your own branch. It is not the job of people that fork to keep compatible with the rest of the world or to merge changes back into the main trunk. Sometimes it happens that original project merges changes from a fork, but the initiative has to come from the original maintainers. This is a good read on the topic: <http://producingoss.com/en/forks.html>. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
My take on this is the following: If you fork you create your own branch. It is not the job of people that fork to keep compatible with the rest of the world or to merge changes back into the main trunk.
Agree on this (I wasn't clear enough in my previous email). However telling the author of the original package that new versions have been produced is not very costly. And if the package author is ready to backport, this is even better, but this is up to him only. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Thanks for the link. This is indeed an excellent reading Alexandre On 9 May 2009, at 23:11, Lukas Renggli wrote:
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Sat, May 9, 2009 at 23:11, Lukas Renggli <renggli@gmail.com> wrote:
I guess you are talking about named branches. This was broken for a while as people used dots in their initials, but Julien and I provided patches that are included in recent versions of Pharo. We use named-branches in Seaside and in various commercial projects extensively.
Exactly. And of the lack of support from MC Browser or Squeaksource at the user level. I know that each snapshot is a branch, but relying on a naming convention that isn't even enforced kinda sucks (what breaks if I commit MyPackage.initials.42.mcz, but change the file name to foobar.mcz before saving?). In Seaside, you can maintain it because you really pay attention or are used to it and know MC well.
My take on this is the following: If you fork you create your own branch. It is not the job of people that fork to keep compatible with the rest of the world or to merge changes back into the main trunk. Sometimes it happens that original project merges changes from a fork, but the initiative has to come from the original maintainers. This is a good read on the topic: <http://producingoss.com/en/forks.html>.
Sure, but it's also good practice to announce at least that you do changes, or better send the changes (fire and forget, but at least the upstream maintainers can go through them and follow if they wish). I have friends working for a linux distro and they often complain that some other distro fixes stuff without notifying upstream, so not only upstream is not notified of bugs and fixes, but every distro duplicates some the fixes and misses some others. Since most fixes could benefit to most forks, it's just a waste of ressources and does more against propagating fixes than otherwise. -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
participants (4)
-
Alexandre Bergel -
Damien Pollet -
Lukas Renggli -
Stéphane Ducasse