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


<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/172#issuecomment-354023920">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AhLyW5YHW82fFq50LxYxU1SWDbypjUALks5tEX6_gaJpZM4QetkG">mute the thread</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/AhLyW3pHZvKBwgDmlxPB7zUK9J1Fol7Zks5tEX6_gaJpZM4QetkG.gif" width="1" /></p>
<div itemscope itemtype="http://schema.org/EmailMessage">
<div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
  <link itemprop="url" href="https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/172#issuecomment-354023920"></link>
  <meta itemprop="name" content="View Issue"></meta>
</div>
<meta itemprop="description" content="View this Issue on GitHub"></meta>
</div>

<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/OpenSmalltalk/opensmalltalk-vm","title":"OpenSmalltalk/opensmalltalk-vm","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/OpenSmalltalk/opensmalltalk-vm"}},"updates":{"snippets":[{"icon":"PERSON","message":"@bencoman in #172: A side-comment from the peanut gallery...\n\nOn 16 November 2017 at 03:47, Fabio Niephaus \u003cnotifications@github.com\u003e\nwrote:\n\n\u003e It is indeed. I was hoping we do \"you break it, you fix it\", but that\n\u003e didn't work apparently.\n\u003e\nTaking the path of least resistance is human nature.  There are varying\nlevels of \"too busy to fix that right now.\"  Introducing the merge-barrier\nshifts that balance point to encourage the idealistic behaviour of fixing\nerrors asap.\n\nTo mitigate concerns of delayed merges..\nIf these barriers sometimes get in the way of something critical, it should\nbe okay to temporarily disable them.  But at least the default encourages\nthe ideal behaviour and bypassing that require explicit action rather than\nhappening accidentally.\n\n\u003e We could force the Cog branch to always be green by only allowing changes\n\u003e that previously have been proven to pass, but then it takes longer to get\n\u003e things merged. Not sure if we want that...\n\u003e\nDelayed merges are a fairly generic concern.  It would be good to expose\nsome detail from everyone concerned that enabling the following will\nimpeded their workflow...\n\nhttps://help.github.com/assets/images/help/repository/protecting-branch-loose-status.png\n\nThat is...\nWhat period of delay are you concerned about?\nHow often do you you think this would be a problem?\nIs the problem the delay in merging-code, or the delay in getting the new\nbinary to run?\n\ncheers -ben\n"}],"action":{"name":"View Issue","url":"https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/172#issuecomment-354023920"}}}</script>