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

[Yves Jacolin]

In my wishlist of waiting PR, we had this one (OGC Filters to WMS in
QGIS server) : https://github.com/qgis/QGIS/pull/5561 :)

Y.


Le 28/11/2017 à 09:42, DelazJ a écrit :
> Hi,
> There's a pull-request i'm missing in the list since the beginning:
> https://github.com/qgis/QGIS/pull/4305
> I'm not sure it'd break an API, and it looks like a new feature but I
> think it'd be a shame to not have it for 3.0. I don't know if Nathan
> has time to work on it but this is a nice tool to help users migrate
> from 2.x to 3.0 easily. I'm not sure it will get enough sense in 3.2
> when a lot of people would have already (maybe) struggled to move
> their settings, unless I overestimate the PR scope and there's already
> a migration process I did not find.
>
> Regards,
> Harrissou
>
> 2017-11-28 3:11 GMT+01:00 Mathieu Pellerin <nirvn.asia at gmail.com
> <mailto:nirvn.asia at gmail.com>>:
>
>     +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
>     <mailto:nyall.dawson at gmail.com>> wrote:
>
>         On 27 November 2017 at 08:32, Tim Sutton <tim at kartoza.com
>         <mailto: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
>         <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
>         <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
>         <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
>         <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 <mailto:Qgis-psc at lists.osgeo.org>
>         https://lists.osgeo.org/mailman/listinfo/qgis-psc
>         <https://lists.osgeo.org/mailman/listinfo/qgis-psc>
>
>
>     _______________________________________________
>     Qgis-psc mailing list
>     Qgis-psc at lists.osgeo.org <mailto:Qgis-psc at lists.osgeo.org>
>     https://lists.osgeo.org/mailman/listinfo/qgis-psc
>     <https://lists.osgeo.org/mailman/listinfo/qgis-psc>
>
>
>
>
> _______________________________________________
> 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/551fcb4b/attachment.html>