Re: [Pharo-project] Question about O2 dependencies
On Tue, Jan 19, 2010 at 2:33 PM, David Roethlisberger <roethlis@iam.unibe.ch
wrote:
Ok. Good. Right now, the Pharo community decided to use Lukas' repository
instead of Colin's one, but I guess it can be merged. Lukas ?
I find it unfriendly to merge into a foreign repository -- pull, fork and
merge in your own repository. And eventually ask the maintainer to merge the code.
I'm confused. What is the right process to update OB for Pharo now? In Pharo-dev, as far as I see, OB is still taken from Colin's repo. Is this gonna change now? Where should I commit a patch to OB now, to Colin's, to Lukas' repo, somewhere else?
Maybe best would be to have a non-personal repo on squeaksource which can be used by all OB developers and from where Pharo takes the code?
David
I am confused too. Actually, this is exactly what I asked when people suggested to use Lukas' OB.
I'm confused. What is the right process to update OB for Pharo now? In Pharo-dev, as far as I see, OB is still taken from Colin's repo. Is this gonna change now? Where should I commit a patch to OB now, to Colin's, to Lukas' repo, somewhere else?
Maybe best would be to have a non-personal repo on squeaksource which can be used by all OB developers and from where Pharo takes the code?
David
I am confused too. Actually, this is exactly what I asked when people suggested to use Lukas' OB.
David, I think that all the code should be on squeaksource: http://www.squeaksource.com/O2.html is still free. The way to update O2 in Pharo should not be different than for Mondrian, Moose, and other. The ConfigurationOfO2 should do this. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Tue, Jan 19, 2010 at 2:47 PM, Alexandre Bergel <alexandre@bergel.eu>wrote:
I'm confused. What is the right process to update OB for Pharo now? In Pharo-dev, as far as I see, OB is still taken from Colin's repo. Is this gonna change now? Where should I commit a patch to OB now, to Colin's, to Lukas' repo, somewhere else?
Maybe best would be to have a non-personal repo on squeaksource which can be used by all OB developers and from where Pharo takes the code?
David
I am confused too. Actually, this is exactly what I asked when people suggested to use Lukas' OB.
David, I think that all the code should be on squeaksource: http://www.squeaksource.com/O2.html is still free. The way to update O2 in Pharo should not be different than for Mondrian, Moose, and other. The ConfigurationOfO2 should do this.
+1 However, here they were not discussing about O2, but about OB. It seems David (or both of you) have cleaned some stuff from OB related to O2. So...the question was where to commit that and how that is merged to Lukas' OB which is what we are using now for PharoDev images.
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: 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
2010/1/19 Mariano Martinez Peck <marianopeck@gmail.com>:
On Tue, Jan 19, 2010 at 2:33 PM, David Roethlisberger <roethlis@iam.unibe.ch> wrote:
Ok. Good. Right now, the Pharo community decided to use Lukas' repository instead of Colin's one, but I guess it can be merged. Lukas ?
I find it unfriendly to merge into a foreign repository -- pull, fork and merge in your own repository. And eventually ask the maintainer to merge the code.
I'm confused. What is the right process to update OB for Pharo now? In Pharo-dev, as far as I see, OB is still taken from Colin's repo. Is this gonna change now? Where should I commit a patch to OB now, to Colin's, to Lukas' repo, somewhere else?
Maybe best would be to have a non-personal repo on squeaksource which can be used by all OB developers and from where Pharo takes the code?
David
I am confused too. Actually, this is exactly what I asked when people suggested to use Lukas' OB.
Public code repositories do not work. I learned that with Seaside, and we all saw that in all its ugliness with OmniBrowser. If this is a popular project in a public repository people will commit changes to that repository. Some of the committed changes are ... - untested - break existing tests - break the architecture - break other code - put into the wrong package - only working for the committer - badly formatted or commented - depend on non-existing code - ... Now, if nobody constantly observes that repository and cleans it up, you have an enormous mess. There are basically dozens of forks and nobody knows what works, what is broken, what is official, what to load, what to use, where to continue with development, etc. And that's not even the end of it. The next thing that happens is that people start to merge: so random versions with random changes are merged in a random order. As a result the problems and bugs multiply. After I saw GitHub, I realized that in the open-source world only read-only code repositories work. The cool thing is that Monticello and Git have a very similar model, so we just have to adapt their process: - Every open-source project has a public read-only repository. Only core contributes that trust each other can commit into this repository. - If I want to change something, submit a bug-fix, or an enhancement I simply fork the complete code base and commit it into my own repository. - As a nice open-source contributor I ask one of the official maintainers to merge my changes by pointing them to my repository: - If they like the changes, they will merge them into the official repository. - If they don't like the changes, that's fine too. I have my own repository and can use the code in there. That's it. It is simple and works really well. That's why my OB repository is read-only. I know that the code in there passes all tests and that it does exactly what I want. Please fork it, improve it, fix things, etc. If I learn about the changes and if I like them I will merge them (that's what I did with some of the O2 code). I do not commit my changes to Colin's repository though, if he wants the code he can pull it (that's what he did in the past too). Lukas -- Lukas Renggli http://www.lukas-renggli.ch
I know exactly what you feel for this. Regards, Gary ----- Original Message ----- From: "Lukas Renggli" <renggli@gmail.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Tuesday, January 19, 2010 6:15 PM Subject: Re: [Pharo-project] Question about O2 dependencies
2010/1/19 Mariano Martinez Peck <marianopeck@gmail.com>:
On Tue, Jan 19, 2010 at 2:33 PM, David Roethlisberger <roethlis@iam.unibe.ch> wrote:
Ok. Good. Right now, the Pharo community decided to use Lukas' repository instead of Colin's one, but I guess it can be merged. Lukas ?
I find it unfriendly to merge into a foreign repository -- pull, fork and merge in your own repository. And eventually ask the maintainer to merge the code.
I'm confused. What is the right process to update OB for Pharo now? In Pharo-dev, as far as I see, OB is still taken from Colin's repo. Is this gonna change now? Where should I commit a patch to OB now, to Colin's, to Lukas' repo, somewhere else?
Maybe best would be to have a non-personal repo on squeaksource which can be used by all OB developers and from where Pharo takes the code?
David
I am confused too. Actually, this is exactly what I asked when people suggested to use Lukas' OB.
Public code repositories do not work. I learned that with Seaside, and we all saw that in all its ugliness with OmniBrowser.
If this is a popular project in a public repository people will commit changes to that repository. Some of the committed changes are ...
- untested - break existing tests - break the architecture - break other code - put into the wrong package - only working for the committer - badly formatted or commented - depend on non-existing code - ...
Now, if nobody constantly observes that repository and cleans it up, you have an enormous mess. There are basically dozens of forks and nobody knows what works, what is broken, what is official, what to load, what to use, where to continue with development, etc.
And that's not even the end of it. The next thing that happens is that people start to merge: so random versions with random changes are merged in a random order. As a result the problems and bugs multiply.
After I saw GitHub, I realized that in the open-source world only read-only code repositories work. The cool thing is that Monticello and Git have a very similar model, so we just have to adapt their process:
- Every open-source project has a public read-only repository. Only core contributes that trust each other can commit into this repository.
- If I want to change something, submit a bug-fix, or an enhancement I simply fork the complete code base and commit it into my own repository.
- As a nice open-source contributor I ask one of the official maintainers to merge my changes by pointing them to my repository:
- If they like the changes, they will merge them into the official repository.
- If they don't like the changes, that's fine too. I have my own repository and can use the code in there.
That's it. It is simple and works really well.
That's why my OB repository is read-only. I know that the code in there passes all tests and that it does exactly what I want. Please fork it, improve it, fix things, etc. If I learn about the changes and if I like them I will merge them (that's what I did with some of the O2 code). I do not commit my changes to Colin's repository though, if he wants the code he can pull it (that's what he did in the past too).
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
lukas could you copy the icons I did from O2 :) steal them please :) Stef On Jan 19, 2010, at 7:15 PM, Lukas Renggli wrote:
2010/1/19 Mariano Martinez Peck <marianopeck@gmail.com>:
On Tue, Jan 19, 2010 at 2:33 PM, David Roethlisberger <roethlis@iam.unibe.ch> wrote:
Ok. Good. Right now, the Pharo community decided to use Lukas' repository instead of Colin's one, but I guess it can be merged. Lukas ?
I find it unfriendly to merge into a foreign repository -- pull, fork and merge in your own repository. And eventually ask the maintainer to merge the code.
I'm confused. What is the right process to update OB for Pharo now? In Pharo-dev, as far as I see, OB is still taken from Colin's repo. Is this gonna change now? Where should I commit a patch to OB now, to Colin's, to Lukas' repo, somewhere else?
Maybe best would be to have a non-personal repo on squeaksource which can be used by all OB developers and from where Pharo takes the code?
David
I am confused too. Actually, this is exactly what I asked when people suggested to use Lukas' OB.
Public code repositories do not work. I learned that with Seaside, and we all saw that in all its ugliness with OmniBrowser.
If this is a popular project in a public repository people will commit changes to that repository. Some of the committed changes are ...
- untested - break existing tests - break the architecture - break other code - put into the wrong package - only working for the committer - badly formatted or commented - depend on non-existing code - ...
Now, if nobody constantly observes that repository and cleans it up, you have an enormous mess. There are basically dozens of forks and nobody knows what works, what is broken, what is official, what to load, what to use, where to continue with development, etc.
And that's not even the end of it. The next thing that happens is that people start to merge: so random versions with random changes are merged in a random order. As a result the problems and bugs multiply.
After I saw GitHub, I realized that in the open-source world only read-only code repositories work. The cool thing is that Monticello and Git have a very similar model, so we just have to adapt their process:
- Every open-source project has a public read-only repository. Only core contributes that trust each other can commit into this repository.
- If I want to change something, submit a bug-fix, or an enhancement I simply fork the complete code base and commit it into my own repository.
- As a nice open-source contributor I ask one of the official maintainers to merge my changes by pointing them to my repository:
- If they like the changes, they will merge them into the official repository.
- If they don't like the changes, that's fine too. I have my own repository and can use the code in there.
That's it. It is simple and works really well.
That's why my OB repository is read-only. I know that the code in there passes all tests and that it does exactly what I want. Please fork it, improve it, fix things, etc. If I learn about the changes and if I like them I will merge them (that's what I did with some of the O2 code). I do not commit my changes to Colin's repository though, if he wants the code he can pull it (that's what he did in the past too).
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Very interesting explanations indeed ! What would be nice is to have similar functionalities than GitHub for SqueakSource and more community aspects. 2010/1/20 Lukas Renggli <renggli@gmail.com>:
2010/1/19 Mariano Martinez Peck <marianopeck@gmail.com>:
On Tue, Jan 19, 2010 at 2:33 PM, David Roethlisberger <roethlis@iam.unibe.ch> wrote:
Ok. Good. Right now, the Pharo community decided to use Lukas' repository instead of Colin's one, but I guess it can be merged. Lukas ?
I find it unfriendly to merge into a foreign repository -- pull, fork and merge in your own repository. And eventually ask the maintainer to merge the code.
I'm confused. What is the right process to update OB for Pharo now? In Pharo-dev, as far as I see, OB is still taken from Colin's repo. Is this gonna change now? Where should I commit a patch to OB now, to Colin's, to Lukas' repo, somewhere else?
Maybe best would be to have a non-personal repo on squeaksource which can be used by all OB developers and from where Pharo takes the code?
David
I am confused too. Actually, this is exactly what I asked when people suggested to use Lukas' OB.
Public code repositories do not work. I learned that with Seaside, and we all saw that in all its ugliness with OmniBrowser.
If this is a popular project in a public repository people will commit changes to that repository. Some of the committed changes are ...
- untested - break existing tests - break the architecture - break other code - put into the wrong package - only working for the committer - badly formatted or commented - depend on non-existing code - ...
Now, if nobody constantly observes that repository and cleans it up, you have an enormous mess. There are basically dozens of forks and nobody knows what works, what is broken, what is official, what to load, what to use, where to continue with development, etc.
And that's not even the end of it. The next thing that happens is that people start to merge: so random versions with random changes are merged in a random order. As a result the problems and bugs multiply.
After I saw GitHub, I realized that in the open-source world only read-only code repositories work. The cool thing is that Monticello and Git have a very similar model, so we just have to adapt their process:
- Every open-source project has a public read-only repository. Only core contributes that trust each other can commit into this repository.
- If I want to change something, submit a bug-fix, or an enhancement I simply fork the complete code base and commit it into my own repository.
- As a nice open-source contributor I ask one of the official maintainers to merge my changes by pointing them to my repository:
  - If they like the changes, they will merge them into the official repository.
  - If they don't like the changes, that's fine too. I have my own repository and can use the code in there.
That's it. It is simple and works really well.
That's why my OB repository is read-only. I know that the code in there passes all tests and that it does exactly what I want. Please fork it, improve it, fix things, etc. If I learn about the changes and if I like them I will merge them (that's what I did with some of the O2 code). I do not commit my changes to Colin's repository though, if he wants the code he can pull it (that's what he did in the past too).
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Smalltalkers do: [:it | All with: Class, (And love: it)] http://doesnotunderstand.org/
We have it have a look at Gofer fetch and push Stef On Jan 20, 2010, at 3:55 AM, Serge Stinckwich wrote:
Very interesting explanations indeed ! What would be nice is to have similar functionalities than GitHub for SqueakSource and more community aspects.
2010/1/20 Lukas Renggli <renggli@gmail.com>:
2010/1/19 Mariano Martinez Peck <marianopeck@gmail.com>:
On Tue, Jan 19, 2010 at 2:33 PM, David Roethlisberger <roethlis@iam.unibe.ch> wrote:
Ok. Good. Right now, the Pharo community decided to use Lukas' repository instead of Colin's one, but I guess it can be merged. Lukas ?
I find it unfriendly to merge into a foreign repository -- pull, fork and merge in your own repository. And eventually ask the maintainer to merge the code.
I'm confused. What is the right process to update OB for Pharo now? In Pharo-dev, as far as I see, OB is still taken from Colin's repo. Is this gonna change now? Where should I commit a patch to OB now, to Colin's, to Lukas' repo, somewhere else?
Maybe best would be to have a non-personal repo on squeaksource which can be used by all OB developers and from where Pharo takes the code?
David
I am confused too. Actually, this is exactly what I asked when people suggested to use Lukas' OB.
Public code repositories do not work. I learned that with Seaside, and we all saw that in all its ugliness with OmniBrowser.
If this is a popular project in a public repository people will commit changes to that repository. Some of the committed changes are ...
- untested - break existing tests - break the architecture - break other code - put into the wrong package - only working for the committer - badly formatted or commented - depend on non-existing code - ...
Now, if nobody constantly observes that repository and cleans it up, you have an enormous mess. There are basically dozens of forks and nobody knows what works, what is broken, what is official, what to load, what to use, where to continue with development, etc.
And that's not even the end of it. The next thing that happens is that people start to merge: so random versions with random changes are merged in a random order. As a result the problems and bugs multiply.
After I saw GitHub, I realized that in the open-source world only read-only code repositories work. The cool thing is that Monticello and Git have a very similar model, so we just have to adapt their process:
- Every open-source project has a public read-only repository. Only core contributes that trust each other can commit into this repository.
- If I want to change something, submit a bug-fix, or an enhancement I simply fork the complete code base and commit it into my own repository.
- As a nice open-source contributor I ask one of the official maintainers to merge my changes by pointing them to my repository:
- If they like the changes, they will merge them into the official repository.
- If they don't like the changes, that's fine too. I have my own repository and can use the code in there.
That's it. It is simple and works really well.
That's why my OB repository is read-only. I know that the code in there passes all tests and that it does exactly what I want. Please fork it, improve it, fix things, etc. If I learn about the changes and if I like them I will merge them (that's what I did with some of the O2 code). I do not commit my changes to Colin's repository though, if he wants the code he can pull it (that's what he did in the past too).
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Smalltalkers do: [:it | All with: Class, (And love: it)] http://doesnotunderstand.org/
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (6)
-
Alexandre Bergel -
Gary Chambers -
Lukas Renggli -
Mariano Martinez Peck -
Serge Stinckwich -
Stéphane Ducasse