Fractal Development (was Re: [Vm-dev] VM Automated builds update)

Casey Ransberger casey.obrien.r at gmail.com
Thu Mar 17 22:46:56 UTC 2011


I think I just have to crash this thread; renaming to be polite about it. 

Distributed SCM, thrown around a lot on the list. Continuous integration is a pretty obvious win I think (if you can convince me that it isn't I'll buy you a whole case of beer.) So I'll just look at source control. 

It works for the Linux kernel. In particular, it makes it possible for a *single individual* to handle integration for the whole kernel, by farming out the detail work to "trusted lieutenants," who in turn do the same for still others. Code starts flowing all over the place, and if it's useful it usually makes it's way back up the tree. 

Does the "single individual" part scream Smalltalk at anyone else, or is it just me?

Think of it as a fractal development model wherein you have much testing and vetting at many levels before e.g. Torvalds ever sees it your commit. 

Some folks seem worried that a decentralized SCM will encourage more forks. I would maintain that forking is a social behavior, and it's unrelated to SCM.

I think we will always have a core of people who "own" pieces of Squeak as a consequence of some combination of meritorious conduct, passion for the technology, etc. There's no need to ditch official releases to accommodate a distributed SCM. Frankly MC is already a hair closer to Git than it is to CVS in some respects, and all the damned thing really needs to get all this goodness rolling (on a technical level anyway) is branching functionality. 

Branch+Merge != Fork

FWIW, the point is making branching and *especially* merging easier. When merging is easy, you have a force that acts *against* divergent enterprises. 

How many forks are there of Squeak? Okay, now how many forks are there of the Linux kernel?

Is the orthogonality obvious yet?

On Mar 17, 2011, at 2:02 PM, stephane ducasse <stephane.ducasse at gmail.com> wrote:

> 
>>>>>>> 
>>> You can continue to bash us saying that we are nasty newbies. Right now we are building an **open** and welcoming architecture
>>> to sustain real open development VMs. This is ok that you do not like it, this is ok too that you bash us. If this helps you feel better
>>> I cannot do much about it.
>> 
>> Did I bash you? No, I said it's "nice and great".
> 
> Excellent then :)
>> 
>>> 
>>> We want VMs to be maintained not just a small (tiny, microscopic) club of people that may be
>>> distracted/not willing to communicate/not have the time to build a vms. We want to make sure that if a guy has time to improve a vm he will not get frustrated because of millions of stupid details: this is what is called software engineering (vs. handcraft). Having a solid automated process is the key to progress in constraints resources. We want to minimize risk for business.
>> 
>> Great.
>> 
>>> 
>>> Also we want to send a clear message to smart C, assembler people that lurk at our technology: they are welcome to participate and help
>>> because the architecture is open. They do not have to ask for a blessing (knights period is over). They can clone, hack and push/share changes and people can cherry pick the changes without having to have the permissions to publish.
>> 
>> That sounds good, but it may not be true.
>> Do you mean that there won't be official VM releases anymore?
>> Or if there will be, then who will decide which changes/features will be included in those?
> 
> apparently you do not really understand what is a distributed source management system.
> this is not because people can clone code and publish their own fixes that there is not somebody in charge of taking decision to integrate a fix or not. Now with git or system like that people can publish integrated code and VM maintainers can cherry pick the changes. In addition, imagine the near future where we will have automatic regression tests about all the produced VMs. then 
> suddenly we will know the impact of a change. Now since we do not have any regression tests it is more difficult to control quality.
> Finally of course this may create a bit of noise but the most important aspect is that if somebody was in capability of helping but 
> did not because of time constraints or other, the current set up can help this person to join effort. 
> 
>>> For example, igor sent a fix for the Windows vm for the semaphore input more than a year ago and it was never integrated.
>> 
>> Yeah, that's annoying, I had the same experience earlier.
>> 
>>> I'm happy that igor decided to stay in our community. Now we can ask ourselves (lot of people don't and after complain that smalltalk is a dead language) how many people came and left. Sharing is key.
>>> 
>>> Now we will have a Windows VM built everyday (this is a fresh news ;) and more than 8 years I'm dreaming about that.
>>> And all the community will be able to use it, if they want. Nobody forces you to use our infrastructure but there will be a lot of advantages. It is free and maintained.
>> 
>> Great.
> 


More information about the Vm-dev mailing list