<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 27 April 2018 at 15:59, Brad Jorsch (Anomie) <span dir="ltr"><<a href="mailto:bjorsch@wikimedia.org" target="_blank">bjorsch@wikimedia.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><div><br></div></span><div>I'd hate to see people mangling[1] the git log by submitting and merging patch chains for updating individual files of a single logical change just to satisfy this SWAT requirement. I'd hate even more if people do that in mediawiki/core master (versus splitting an existing patch while backporting), to the point where I'd recommend -2ing such patch-chains there.<br></div></div></div></div></blockquote></div><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Those are good points, but I disagree that these are specific to SWAT. I assume we all want things like "Keeping the site up", and "Verify code in a representative and meaningful way before deploying to production". Regardless of whether someone deploys on their own, or uses the convenience of SWAT.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The bottom line is that each commit should be verifiable and deployable. The changes to the SWAT policy ensure that:</div><div class="gmail_extra"><br></div><div class="gmail_extra">* Verifiable: Can be staged on tin and staged on mwdebug1002 in a way is representative of actual deployment.</div><div class="gmail_extra">* Deployable: Can be deployed in one step, and the deployed state matches Git, and can be reverted in one step if needed.</div><div class="gmail_extra"><br></div><div class="gmail_extra">These are incompatible with syncing a patch in two steps. Such as adding a variable, dblist or function; and referencing it from another file. Because if you do, our current deployment workflow will not result in a state on mwdebug1002 that matches the result of the (first) sync command. As such, the verification is not as meaningful given actual sync may still break the site. This has happened on more than one occasion, in part because we don't have strict pre-promote checks[1] (although it is being worked on).</div><div class="gmail_extra"><br></div><div class="gmail_extra">Making complex changes and refactors in mediawiki/core is fine. But if it can't wait for the train or can't be given its own window with full scap, it will need to be broken down into smaller changes that each can be safely merged, beta'ed, cherry-picked, verified and deployed.</div><div class="gmail_extra"><br></div><div class="gmail_extra">-- Timo</div><div class="gmail_extra"><br></div><div class="gmail_extra">[1] <a href="https://phabricator.wikimedia.org/T121597">https://phabricator.wikimedia.org/T121597</a></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div></div>