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@github.com wrote:
A side-comment from the peanut gallery...
On 16 November 2017 at 03:47, Fabio Niephaus notifications@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-loos...
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.
vm-dev@lists.squeakfoundation.org