<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Apr 28, 2018 at 1:33 AM, Timo Tijhof <span dir="ltr"><<a href="mailto:ttijhof@wikimedia.org" target="_blank">ttijhof@wikimedia.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class=""><div class="gmail_extra"><div class="gmail_quote">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></span></div></blockquote><div><br></div><div>OTOH core patches are tested way better than backports (which often have to be forced through CI which is not all that reliable for old branches; also backports are often not done by the developer of the code). Forcing people to rewrite backports as multiple patches instead of just cherry-picking might introduce more risk of error than it takes away. An alternative approach would be to require a sync plan for config / backport patches, and make that a requirement for +1 (and add a scap pull-file command).</div></div></div></div>