Forks (Re: [Vm-dev] a Cog branch)

[Igor Stasenko]

On 25 June 2010 12:29, laurent laffont <laurent.laffont at gmail.com> wrote:
>
>
> On Fri, Jun 25, 2010 at 10:56 AM, Andreas Raab <andreas.raab at gmx.de> wrote:
>>
>> On 6/25/2010 1:41 AM, Casey Ransberger wrote:
>>>
>>> So I guess what I'm saying is that I think we shouldn't worry at all about forks, and that statement includes not worrying at all about being compatible with forks. If I wanted to fork Squeak (and I do from time to time,) quite frankly, I think it would be unreasonable to expect Squeak to be compatible with my fork; when you fork, you're on your own. Anyone who's ever maintained a fork of something knows this from personal experience.
>>>
>>> Now back to SCM. There are some nice wins with Git over Subversion, mostly to do with fast merges and distributed development. In fact I'd like it if we learned some things from Git in our further development of Monticello.
>>
>> I agree with merging (the only argument that carries any weight here). I don't buy the forking argument. The number of people building VMs is *tiny* compared to general Squeak users. Having those fork instead of pool their resources is an absolutely deadly fallacy. As a consequence, I think that it's a Very Good Thing (tm) having to pay a price for forking. It should be easier to contribute back to main line sources than to fork.
>
> I try an argument.
> Now vm-dev team uses SVN, and there's forks. But you don't know it. They may be wonderful patches, they're lost on people hard disks.
> With a DVCS there will be forks too. But you know it, you can track it, others can try it and say "hey this is cool, it works, merge it please !".
> IMHO it's really important that fork is easy. Look at the Linux kernel, it's wonderful.

This is exactly why i proposed to use github.
Because with it, its very easy to merge the changes between forks.
But what is most important - nothing is lost.

> Laurent
>
>
>>
>>> But for the love of God, can we keep Cog in the same repository that we keep the rest of the Squeak VMs? Maybe we switch to Git or Mercurial for managing C sources eventually, but we should do it across the board. Squeak is (from the moment they decided to actually use the Blue Book sources as a starting point) a *reference implementation.* You really don't want more than one of those.
>>
>> Absolutely. Eliot's initial point was exactly that, i.e., decouple the discussion about a change in SCM from having a Cog branch. I don't think anyone is arguing that point.
>>
>>> I'm going to pull a total Jack-move and call Godwin's Law on myself in a shameless attempt to kill this subject as quickly as possible: Hitler.
>>
>> :-)
>>
>> Cheers,
>>  - Andreas
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.