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

[Eliot Miranda]

> On Mar 18, 2016, at 11:21 PM, stephane ducasse <stephane.ducasse at gmail.com> wrote:
> 
> 
>> 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. 

but you never thought to have Igor consult me and come up with a build structure is be happy with.  And I'm not happy with the VM infrastructure in the Pharo build and I hope that we can agree on a single build infrastructure, which clearly separates C VM generation from C VM compilation.

>> 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>:
>>> 
>>> 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/6b8663af/attachment.htm