[Vm-dev] [OpenSmalltalk/opensmalltalk-vm] Fix all CI builds (#172)

[Esteban Lorenzano]

heh… I have to say: I do not contribute to osvm other than PRs (never directly), so I always expect having a green build to merge. Also, I always have first a green build in my own build process (who builds all sources from scratch and tests the resulting VM executing all tests in Pharo), so when I do the PR, I tested my sources.
The problem we had with Pharo was because of two colliding issues (non related):

- server destination for deploy changed, and then keys became immediately wrong
- travis updated his server and didn’t included by default anymore libcurl for i386

this escapes the “you break it, you fix it” 

I agree no contribution should be accepted if it does not passes through a PR (and CI needs to pass), but that’s actually hard to do with current process: today VMMaker monticello is the “development branch” and you cannot prepare PRs with that… you need branch before generate sources, then commit into branch and then PR. I would recommend to use that approach but is more work than just commit so hard to adopt. 

Esteban

> On 27 Dec 2017, at 00:18, Ben Coman <notifications at github.com> wrote:
> 
> A side-comment from the peanut gallery...
> 
> On 16 November 2017 at 03:47, Fabio Niephaus <notifications at github.com>
> wrote:
> 
> > It is indeed. I was hoping we do "you break it, you fix it", but that
> > didn't work apparently.
> >
> Taking the path of least resistance is human nature. There are varying
> levels of "too busy to fix that right now." Introducing the merge-barrier
> shifts that balance point to encourage the idealistic behaviour of fixing
> errors asap.
> 
> To mitigate concerns of delayed merges..
> If these barriers sometimes get in the way of something critical, it should
> be okay to temporarily disable them. But at least the default encourages
> the ideal behaviour and bypassing that require explicit action rather than
> happening accidentally.
> 
> > We could force the Cog branch to always be green by only allowing changes
> > that previously have been proven to pass, but then it takes longer to get
> > things merged. Not sure if we want that...
> >
> Delayed merges are a fairly generic concern. It would be good to expose
> some detail from everyone concerned that enabling the following will
> impeded their workflow...
> 
> https://help.github.com/assets/images/help/repository/protecting-branch-loose-status.png
> 
> That is...
> What period of delay are you concerned about?
> How often do you you think this would be a problem?
> Is the problem the delay in merging-code, or the delay in getting the new
> binary to run?
> 
> cheers -ben
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub <https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/172#issuecomment-354023920>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAfWXhk8Fm6tVkwyY5Q_BvaSHcwL6Wb2ks5tEX6_gaJpZM4QetkG>.
> 



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/172#issuecomment-354101924
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20171227/73b0a233/attachment.html>