On 27 December 2017 at 22:43, Esteban Lorenzano <notifications@github.com><br>
wrote:<br>
<br>
> heh… I have to say: I do not contribute to osvm other than PRs (never<br>
> directly), so I always expect having a green build to merge. Also, I always<br>
> have first a green build in my own build process (who builds all sources<br>
> from scratch and tests the resulting VM executing all tests in Pharo), so<br>
> when I do the PR, I tested my sources.<br>
> The problem we had with Pharo was because of two colliding issues (non<br>
> related):<br>
><br>
> - server destination for deploy changed, and then keys became immediately<br>
> wrong<br>
<br>
<br>
Sure, this is an anomaly that shouldn't occur too often. Its kind of an<br>
act-of-god event.<br>
But to remove such external dependency maybe each distribution's<br>
"deployment"<br>
could move to an isolated pipeline stage, so one distribution's deploy<br>
infrastructure<br>
can never affect the status of the build itself.<br>
https://blog.travis-ci.com/2017-05-11-introducing-build-stages<br>
<br>
<br>
<br>
> - travis updated his server and didn’t included by default anymore libcurl<br>
> for i386<br>
<br>
<br>
> this escapes the “you break it, you fix it”<br>
<br>
I agree no contribution should be accepted if it does not passes through a<br>
> PR (and CI needs to pass), but that’s actually hard to do with current<br>
> process: today VMMaker monticello is the “development branch” and you<br>
> cannot prepare PRs with that… you need branch before generate sources,<br>
<br>
<br>
Actually you can create and change to a new branch after you generate<br>
sources if you forget to do it before.<br>
See accepted answer here...<br>
https://stackoverflow.com/questions/2569459/git-create-a-branch-from-unstaged-uncommitted-changes-on-master<br>
<br>
<br>
<br>
> then commit into branch and then PR. I would recommend to use that<br>
> approach but is more work than just commit so hard to adopt.<br>
><br>
<br>
If one routinely uses branch-per-feature then generating sources from<br>
VMMaker is just another-feature in a familiar workflow.<br>
It balances the distribution a small additional effort per integration<br>
against the work to recover from the occasional slip getting into main<br>
branch.<br>
<br>
I guess the main difficulty is changing workflow habits.  In practice there<br>
is some risk in changing workflows.<br>
Anomalies can always pop up and its about finding the time to build<br>
confidence in a new workflow.<br>
btw, I think the community has gained a lot already in the move from svn to<br>
git/github.<br>
We'll get the next step sometime.<br>
<br>
cheers -ben<br>
<br>
<br>
> Esteban<br>
><br>
> > On 27 Dec 2017, at 00:18, Ben Coman <notifications@github.com> wrote:<br>
> ><br>
> > 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<br>
> 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<br>
> than<br>
> > happening accidentally.<br>
> ><br>
> > > We could force the Cog branch to always be green by only allowing<br>
> changes<br>
> > > that previously have been proven to pass, but then it takes longer to<br>
> 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/<br>
> 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>
> > —<br>
> > You are receiving this because you were mentioned.<br>
> > Reply to this email directly, view it on GitHub <https://github.com/<br>
> OpenSmalltalk/opensmalltalk-vm/issues/172#issuecomment-354023920>, or<br>
> mute the thread <https://github.com/notifications/unsubscribe-<br>
> auth/AAfWXhk8Fm6tVkwyY5Q_BvaSHcwL6Wb2ks5tEX6_gaJpZM4QetkG>.<br>
> ><br>
><br>
> —<br>
> You are receiving this because you commented.<br>
> Reply to this email directly, view it on GitHub<br>
> <https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/172#issuecomment-354101924>,<br>
> or mute the thread<br>
> <https://github.com/notifications/unsubscribe-auth/ABolJ9PrASAaRthpzh5Mj74RQL_Oci7Yks5tEi1-gaJpZM4QetkG><br>
> .<br>
><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-354198767">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AhLyWwtkerXmv8HDKsY2zpjzXHBg38Seks5tEtt5gaJpZM4QetkG">mute the thread</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/AhLyW6A0KPpTlro5TaBSURnSDHJ5coIiks5tEtt5gaJpZM4QetkG.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-354198767"></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: On 27 December 2017 at 22:43, Esteban Lorenzano \u003cnotifications@github.com\u003e\nwrote:\n\n\u003e heh… I have to say: I do not contribute to osvm other than PRs (never\n\u003e directly), so I always expect having a green build to merge. Also, I always\n\u003e have first a green build in my own build process (who builds all sources\n\u003e from scratch and tests the resulting VM executing all tests in Pharo), so\n\u003e when I do the PR, I tested my sources.\n\u003e The problem we had with Pharo was because of two colliding issues (non\n\u003e related):\n\u003e\n\u003e - server destination for deploy changed, and then keys became immediately\n\u003e wrong\n\n\nSure, this is an anomaly that shouldn't occur too often. Its kind of an\nact-of-god event.\nBut to remove such external dependency maybe each distribution's\n\"deployment\"\ncould move to an isolated pipeline stage, so one distribution's deploy\ninfrastructure\ncan never affect the status of the build itself.\nhttps://blog.travis-ci.com/2017-05-11-introducing-build-stages\n\n\n\n\u003e - travis updated his server and didn’t included by default anymore libcurl\n\u003e for i386\n\n\n\u003e this escapes the “you break it, you fix it”\n\nI agree no contribution should be accepted if it does not passes through a\n\u003e PR (and CI needs to pass), but that’s actually hard to do with current\n\u003e process: today VMMaker monticello is the “development branch” and you\n\u003e cannot prepare PRs with that… you need branch before generate sources,\n\n\nActually you can create and change to a new branch after you generate\nsources if you forget to do it before.\nSee accepted answer here...\nhttps://stackoverflow.com/questions/2569459/git-create-a-branch-from-unstaged-uncommitted-changes-on-master\n\n\n\n\u003e then commit into branch and then PR. I would recommend to use that\n\u003e approach but is more work than just commit so hard to adopt.\n\u003e\n\nIf one routinely uses branch-per-feature then generating sources from\nVMMaker is just another-feature in a familiar workflow.\nIt balances the distribution a small additional effort per integration\nagainst the work to recover from the occasional slip getting into main\nbranch.\n\nI guess the main difficulty is changing workflow habits.  In practice there\nis some risk in changing workflows.\nAnomalies can always pop up and its about finding the time to build\nconfidence in a new workflow.\nbtw, I think the community has gained a lot already in the move from svn to\ngit/github.\nWe'll get the next step sometime.\n\ncheers -ben\n\n\n\u003e Esteban\n\u003e\n\u003e \u003e On 27 Dec 2017, at 00:18, Ben Coman \u003cnotifications@github.com\u003e wrote:\n\u003e \u003e\n\u003e \u003e A side-comment from the peanut gallery...\n\u003e \u003e\n\u003e \u003e On 16 November 2017 at 03:47, Fabio Niephaus \u003cnotifications@github.com\u003e\n\u003e \u003e wrote:\n\u003e \u003e\n\u003e \u003e \u003e It is indeed. I was hoping we do \"you break it, you fix it\", but that\n\u003e \u003e \u003e didn't work apparently.\n\u003e \u003e \u003e\n\u003e \u003e Taking the path of least resistance is human nature. There are varying\n\u003e \u003e levels of \"too busy to fix that right now.\" Introducing the merge-barrier\n\u003e \u003e shifts that balance point to encourage the idealistic behaviour of fixing\n\u003e \u003e errors asap.\n\u003e \u003e\n\u003e \u003e To mitigate concerns of delayed merges..\n\u003e \u003e If these barriers sometimes get in the way of something critical, it\n\u003e should\n\u003e \u003e be okay to temporarily disable them. But at least the default encourages\n\u003e \u003e the ideal behaviour and bypassing that require explicit action rather\n\u003e than\n\u003e \u003e happening accidentally.\n\u003e \u003e\n\u003e \u003e \u003e We could force the Cog branch to always be green by only allowing\n\u003e changes\n\u003e \u003e \u003e that previously have been proven to pass, but then it takes longer to\n\u003e get\n\u003e \u003e \u003e things merged. Not sure if we want that...\n\u003e \u003e \u003e\n\u003e \u003e Delayed merges are a fairly generic concern. It would be good to expose\n\u003e \u003e some detail from everyone concerned that enabling the following will\n\u003e \u003e impeded their workflow...\n\u003e \u003e\n\u003e \u003e https://help.github.com/assets/images/help/repository/\n\u003e protecting-branch-loose-status.png\n\u003e \u003e\n\u003e \u003e That is...\n\u003e \u003e What period of delay are you concerned about?\n\u003e \u003e How often do you you think this would be a problem?\n\u003e \u003e Is the problem the delay in merging-code, or the delay in getting the new\n\u003e \u003e binary to run?\n\u003e \u003e\n\u003e \u003e cheers -ben\n\u003e \u003e —\n\u003e \u003e You are receiving this because you were mentioned.\n\u003e \u003e Reply to this email directly, view it on GitHub \u003chttps://github.com/\n\u003e OpenSmalltalk/opensmalltalk-vm/issues/172#issuecomment-354023920\u003e, or\n\u003e mute the thread \u003chttps://github.com/notifications/unsubscribe-\n\u003e auth/AAfWXhk8Fm6tVkwyY5Q_BvaSHcwL6Wb2ks5tEX6_gaJpZM4QetkG\u003e.\n\u003e \u003e\n\u003e\n\u003e —\n\u003e You are receiving this because you commented.\n\u003e Reply to this email directly, view it on GitHub\n\u003e \u003chttps://github.com/OpenSmalltalk/opensmalltalk-vm/issues/172#issuecomment-354101924\u003e,\n\u003e or mute the thread\n\u003e \u003chttps://github.com/notifications/unsubscribe-auth/ABolJ9PrASAaRthpzh5Mj74RQL_Oci7Yks5tEi1-gaJpZM4QetkG\u003e\n\u003e .\n\u003e\n"}],"action":{"name":"View Issue","url":"https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/172#issuecomment-354198767"}}}</script>