Re: Question about O2 dependencies

> 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.

>
>
> On Tue, Jan 19, 2010 at 2:33 PM, David Roethlisberger
> <[hidden email]> 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.

> 2010/1/19 Mariano Martinez Peck <[hidden email]>:
>>
>>
>> On Tue, Jan 19, 2010 at 2:33 PM, David Roethlisberger
>> <[hidden email]> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project 

> 2010/1/19 Mariano Martinez Peck <[hidden email]>:
>>
>>
>> On Tue, Jan 19, 2010 at 2:33 PM, David Roethlisberger
>> <[hidden email]> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 2010/1/19 Mariano Martinez Peck <[hidden email]>:
>>
>>
>> On Tue, Jan 19, 2010 at 2:33 PM, David Roethlisberger
>> <[hidden email]> 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
> [hidden email]
> 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 <[hidden email]>:
>> 2010/1/19 Mariano Martinez Peck <[hidden email]>:
>>>
>>>
>>> On Tue, Jan 19, 2010 at 2:33 PM, David Roethlisberger
>>> <[hidden email]> 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
>> [hidden email]
>> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project