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

[Nicolas Cellier]

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.

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.

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
;)

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 :(

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/b442f92c/attachment.htm