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/