[QGIS-Developer] [Qgis-psc] QGIS Soft Feature Freeze Voting (was Re: QGIS 3 release expectations)

[Nyall Dawson]

On 27 November 2017 at 08:32, Tim Sutton <tim at kartoza.com> 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