[Vm-dev] VM Maker: VMMaker.oscog-nice.1733.mcz

[stephane ducasse]

> On 19 Mar 2016, at 01:23, Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com> wrote:
> 
> Stephane, that's my fault and I apologize.This time, i've not put enough effort before the commit.
> Instead i've put excessive confidence in the simulator and my previous work in own branch.
> I can only commit nightly, so effectively, it can cost a day before I correct my mistakes.
> 
> HOWEVER, may I remind you the combinatorial:
>  (spur,v3) x (interpreter,cogit) x (32,64bits) x (mac,win,linux,...) x (squeak,pharo,newspeak)
> not speaking of ARM, android free bsd etc...
> How do you conceivably expect that a single contributor like me would perform tests for each and every configuration?
> You naturally put YOUR build above every other, but to me this has no more value than anyone else bias.

I paid igor during six months to have this infrastructure and people can take it and run away with it and use it for there own needs.
And instead of taking advantages we got “oh this is for pharo”. With clement we are checking the kind of slaves we can put in place to 
tests his crazy tests. Because against combinatorial there is machines and automated process. 

> Performing that bunch of tests is not human, only a bot can do it.
> Isn't it what the Jenkins architecture is all about?
> Incorrect commit are correctly detected and should remain unused.
> The commiter should be notified, and that was the case.
> So what do you want more?
> Everyone else duplicating this effort?
> 
> Ggit would help managing development with branches, but we are not there currently, so please revise your standards.

Esteban is managing all with git just because this is easier and empowering us. 
Moving a project to git is not that a big deal. 
I hate git API personnally but I imagine that git should not be a problem for people mastering VM. So 
I do not see the point. The problem here is not technological. But again we are free not to use the tools that can empower us.
But then in that case why using VMmaker and not plain C. You see this is the same argument. 

> You know that I'm not found of the break it first, fix it later strategy.
> Though it sometimes happen that I get caught.
> Here it sounds like you are not granting to me this right to break things when in the same time this right is totally abused in every day Pharo development...
> So despite the fact that you are completely right this time, I'd say that I would have been more inclined to take the lesson I deserved from say Eliot ;)

This is not a question of lesson taken this is a economical point. 
Within a year esteban will leave in another place and have its own company and run for money and the question is 
should he spent time trying to understand and fix things that a simple farm of machine could have caught?

> I'm taking too much time writing this when there's probably more trouble with the spur VM currently and that ain't good.
> Stephane, I like your energy, and I wish I could use and promote Pharo, but please, keep it positive :)
> Tonight, you gave me bad vibrations :(

You see you do not understand my message. So let us not change anything and continue to work like that 
since this is perfect.

> 
> Nicolas
> 
> 
> 2016-03-18 22:13 GMT+01:00 stephane ducasse <stephane.ducasse at gmail.com <mailto:stephane.ducasse at gmail.com>>:
> 
> I wonder why you do not check our builds before pushing a change. Staging changes can make sure that
> we control the propagation of errors. And as you know, error = time = money.
> This is always difficult for someone to try to understand error that he had  no clue from where they come.
> 
> Stef
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160319/3cd106ee/attachment.htm