I know exactly what you feel for this. Regards, Gary
----- Original Message ----- From: "Lukas Renggli" <[email protected]> To: <[email protected]> Sent: Tuesday, January 19, 2010 6:15 PM Subject: Re: [Pharo-project] Question about O2 dependencies > 2010/1/19 Mariano Martinez Peck <[email protected]>: >> >> >> On Tue, Jan 19, 2010 at 2:33 PM, David Roethlisberger >> <[email protected]> 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 > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
