<div dir="auto">+1 to all four PRs, especially the dynamic number value for processing one which I've tested quite a lot in the last 48 hours and couldn't detect any problem.</div><div class="gmail_extra"><br><div class="gmail_quote">On Nov 28, 2017 6:39 AM, "Nyall Dawson" <<a href="mailto:nyall.dawson@gmail.com">nyall.dawson@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 27 November 2017 at 08:32, Tim Sutton <<a href="mailto:tim@kartoza.com">tim@kartoza.com</a>> wrote:<br>
> The voting process is transparent but only qgis/QGIS core committers may vote on it. Please note that if you are eligible you should have received an invite email to join the loomio group. If you did not, please contact me with your preferred email address and I will re-add you.<br>
><br>
<br>
Hi Tim,<br>
<br>
What's the process to get exemptions for open PRs? There's a couple<br>
I'd like to see merged if it's agreeable:<br>
<br>
- <a href="https://github.com/qgis/QGIS/pull/5600" rel="noreferrer" target="_blank">https://github.com/qgis/QGIS/<wbr>pull/5600</a>: "Add order by expression<br>
processing algorithm". Very low risk - it's a self contained algorithm<br>
on which nothing else depends. Processing in 3.0 is awesome, and has<br>
made great strides to becoming a competitive ETL tool. This algorithm<br>
would very nicely complement the work already done in 3.0 to make<br>
models more powerful and flexible.<br>
<br>
- <a href="https://github.com/qgis/QGIS/pull/5430" rel="noreferrer" target="_blank">https://github.com/qgis/QGIS/<wbr>pull/5430</a>: "More output format choices<br>
in raster save as dialog": Low risk. Changes only affect the dialog,<br>
and an extra convenience member in QgsRasterFileWriter (which is<br>
accompanied by unit tests)<br>
<br>
- <a href="https://github.com/qgis/QGIS/pull/5729" rel="noreferrer" target="_blank">https://github.com/qgis/QGIS/<wbr>pull/5729</a>: "[processing] Expose dynamic<br>
("data defined") numeric parameters to gui". Low-medium risk. Most of<br>
the changes here are gui related, just exposing functionality which<br>
already exists in the new processing backend (and which is covered by<br>
stacks of unit tests). I'd love to see this included in 3.0 as it<br>
changes some of the processing API, and I would like wider testing and<br>
porting of algorithms to utilise this BEFORE the API is locked in<br>
place and we're stuck with it. I'd rather identify any issues in the<br>
related API here for 3.0. Additionally, the changes to the "set z<br>
value" algorithm which allows the z value to be pulled from a field or<br>
expression is extremely useful in preparing datasets for use in the<br>
new 3d views. Plus, it's an absolute KILLER feature to have.<br>
<br>
- <a href="https://github.com/qgis/QGIS/pull/5663" rel="noreferrer" target="_blank">https://github.com/qgis/QGIS/<wbr>pull/5663</a>: "Add a name for transactions<br>
created from executeSql". It's marked as a feature and tagged as 3.2,<br>
but looking over it it seems to be almost entirely api tweaks and a<br>
unit test. I'd say this is low risk, especially given Paul's history<br>
of stable commits and how well unit tested this are of code is<br>
already.<br>
<br>
Nyall<br>
______________________________<wbr>_________________<br>
Qgis-psc mailing list<br>
<a href="mailto:Qgis-psc@lists.osgeo.org">Qgis-psc@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/qgis-psc" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/qgis-psc</a></blockquote></div></div>