<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body style='font-size: 10pt; font-family: Verdana,Geneva,sans-serif'>
<p>Hi Nyall,</p>
<p>I knew this discussion would come up soon ;-)</p>
<p>How about: your option 2) with a cut-off date - but only for PRs that need/trigger an API change and without the merge would have to wait for QGIS 4.</p>
<p>In my opinion, new features can wait for QGIS 3.2, but PRs that introduce an API break should be reviewed by a knowledgeable dev and decided on a case-by-case basis.</p>
<p>What would be a reasonable cut-off date? One additional week?</p>
<p>Greetings,</p>
<p>Andreas</p>
<p>On 2017-10-24 00:33, Nyall Dawson wrote:</p>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0"><!-- html ignored --><!-- head ignored --><!-- meta ignored -->
<div class="pre" style="margin: 0; padding: 0; font-family: monospace">Hi all,<br /> <br /> Just wanted to raise discussion about what we should do regarding the<br /> 100+ open PRs currently sitting in the request queue, especially with<br /> regards to the looming freeze.<br /> <br /> I can see two options:<br /> <br /> 1. freeze = freeze, no exceptions. But then we run the risk of people<br /> merging PRs and commits prematurely without full peer review just to<br /> get them in for 3.0 (it becomes a rush of "quick merge in whatever<br /> state because it's a cool feature!!). Or alternatively we may miss<br /> open PRs which are important (crucial?) to have in place for 3.0 (e.g.<br /> processing SAGA/GRASS providers, Nathan's settings migrations, etc).<br /> <br /> 2. Allow open PRs to be merged after freeze on a case-by-case basis,<br /> up to a suitable cut-off date (when?).<br /> <br /> <br /> (FULL DISCLAIMER: I fully acknowledge that my views are biased and I'm<br /> invested here, since I've about to open a PR which ports much of the<br /> remaining missing functionality from composer->layouts, but is not<br /> (yet) 100% complete, and will likely not be by the feature freeze cut<br /> off. It's SO SO close though, and I'd hate it to miss 3.0 and force us<br /> to carry around 10ks of lines of outdated code just to keep api<br /> compatibility with composer for the life of 3.x)<br /> <br /> Nyall<br /> _______________________________________________<br /> QGIS-Developer mailing list<br /> <a href="mailto:QGIS-Developer@lists.osgeo.org">QGIS-Developer@lists.osgeo.org</a><br /> List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank" rel="noopener noreferrer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br /> Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank" rel="noopener noreferrer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></div>
</blockquote>
<p><br /></p>
</body></html>