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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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?


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Sat, May 9, 2009 at 18:05, Stéphane Ducasse
<[hidden email]> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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:

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Sat, May 9, 2009 at 18:59, Stéphane Ducasse
<[hidden email]> 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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On May 9, 2009, at 7:42 PM, Damien Pollet wrote:

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.


_______________________________________________
Pharo-project mailing list
[hidden email]
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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Thanks for the link. This is indeed an excellent reading

Alexandre


On 9 May 2009, at 23:11, Lukas Renggli wrote:

> http://producingoss.com/en/forks.html

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Sat, May 9, 2009 at 23:11, Lukas Renggli <[hidden email]> 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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project