+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.
On Nov 28, 2017 6:39 AM, "Nyall Dawson" <[email protected]> wrote: > On 27 November 2017 at 08:32, Tim Sutton <[email protected]> wrote: > > 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. > > > > Hi Tim, > > What's the process to get exemptions for open PRs? There's a couple > I'd like to see merged if it's agreeable: > > - https://github.com/qgis/QGIS/pull/5600: "Add order by expression > processing algorithm". Very low risk - it's a self contained algorithm > on which nothing else depends. Processing in 3.0 is awesome, and has > made great strides to becoming a competitive ETL tool. This algorithm > would very nicely complement the work already done in 3.0 to make > models more powerful and flexible. > > - https://github.com/qgis/QGIS/pull/5430: "More output format choices > in raster save as dialog": Low risk. Changes only affect the dialog, > and an extra convenience member in QgsRasterFileWriter (which is > accompanied by unit tests) > > - https://github.com/qgis/QGIS/pull/5729: "[processing] Expose dynamic > ("data defined") numeric parameters to gui". Low-medium risk. Most of > the changes here are gui related, just exposing functionality which > already exists in the new processing backend (and which is covered by > stacks of unit tests). I'd love to see this included in 3.0 as it > changes some of the processing API, and I would like wider testing and > porting of algorithms to utilise this BEFORE the API is locked in > place and we're stuck with it. I'd rather identify any issues in the > related API here for 3.0. Additionally, the changes to the "set z > value" algorithm which allows the z value to be pulled from a field or > expression is extremely useful in preparing datasets for use in the > new 3d views. Plus, it's an absolute KILLER feature to have. > > - https://github.com/qgis/QGIS/pull/5663: "Add a name for transactions > created from executeSql". It's marked as a feature and tagged as 3.2, > but looking over it it seems to be almost entirely api tweaks and a > unit test. I'd say this is low risk, especially given Paul's history > of stable commits and how well unit tested this are of code is > already. > > Nyall > _______________________________________________ > Qgis-psc mailing list > [email protected] > https://lists.osgeo.org/mailman/listinfo/qgis-psc
_______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
