[Vm-dev] a Cog branch

Igor Stasenko siguctua at gmail.com
Sat Jun 26 02:17:10 UTC 2010

On 26 June 2010 01:18, stephane ducasse <stephane.ducasse at gmail.com> wrote:
> But andreas if people cannot easily post their contributions then they will leave, or they will fork anyway.
> This is really simple to clone a svn repository.
> We were planning to have a github dedicated to vm contributions so that people investing time to get a better
> make for windows for example can contribute and like that we have no stress that you get busy or not.

Oh you also planned to use it? Cool.

I used github for a single project, and frankly i can't say that i
learnt to use it well.
But from what i have seen, it really helps with organizing a workflow,
where you have multiple
contributors, each doing experiments in own direction, and then sync
the results into a central

It is very easy to track things and don't get lost in the information ocean.

> The VM maintainer can decide if they want it or not. They can cherry pick the changes.
> But we can also access it and use it and contribute to it.
> This is like the immutability it even if it is not introduced then having an entry point to find the
> code is an advantage.
> As igor said git is a tool and you can build a process around it.
> Stef
>> On 6/25/2010 1:59 PM, Bert Freudenberg wrote:
>>> I really cannot understand your objection.
>> Yes, I'm obviously doing a bad job formulating my concern :-)
>> The concern isn't about the utilization of a DVCS. The concern is about people saying "hurray, now we can finally fork". If we're in a situation that people feel that way, then we're doing something wrong and it has nothing to do with the use of a DVCS.
>> So everyone here explaining to me how great it is to fork is doing nothing but deepening my concern that we have a real problem and that the only outcome of a switch to a DVCS is that we'll end up in a multitude of incompatible forks. Which is what I'm trying to avoid.
>> Cheers,
>>  - Andreas

Best regards,
Igor Stasenko AKA sig.

More information about the Vm-dev mailing list