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

[Mathieu Pellerin]

+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" <nyall.dawson at gmail.com> wrote:

> 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
> _______________________________________________
> Qgis-psc mailing list
> Qgis-psc at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/qgis-psc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20171128/65eae2fa/attachment.html>