
<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hi<div class=""><br class=""><blockquote type="cite" class="">On 08 Mar 2016, at 09:16, Alexander Bruy <<a href="mailto:alexander.bruy@gmail.com" class="">alexander.bruy@gmail.com</a>> wrote:<br class=""><br class="">Hi Tim, Nyall,<br class=""><br class="">I understand your points. While new features in most cases can wait<br class="">for next major version, do we really want to miss bugfixes, especially<br class="">for algorithms, which depends on 3rd party backends, e.g. SAGA or<br class="">GRASS [0]? BTW, most PR with such fixes contributed by community<br class="">members. I'm afraid if PR will be unmerged for a long time, we will<br class="">distract users from further contributions.<br class=""></blockquote><div class=""><br class=""></div><div class="">I don’t want to miss bug fixes, but I’d also like to see an architecture in place that limits how bug fixes break existing workflows. In core we manage that by making small wrappers around new methods to keep old API methods working. If a bug fix breaks something else that used to work isn’t the net gain zero? If the bug fix fixes something and doesn’t break something else then the net gain is 1 (good!).</div><br class=""><blockquote type="cite" class=""><br class="">I don't know how many users create models and scripts, but in our<br class="">QGIS-Processing repo there are only small number of them. Maybe<br class="">this is because nobody wants to create scripts/models because<br class="">of unstable Processing API. But also this is can be an indicator that<br class="">very limited number of users create scripts/models.<br class=""></blockquote><div class=""><br class=""></div><div class="">I think think a more likely hypothesis is that most models are probably highly specific to individual peoples workflows and not good candidates for general sharing.</div><div class=""><br class=""></div><div class="">Just to clarify my previous posting, I am not against doing some big overhaul to improve the situation but I would prefer to see that it :</div><div class=""><br class=""></div><div class="">a) happens with 3.0 when we are breaking a bunch of stuff anyway and</div><div class="">b) moves in a direction where the underlying architecture is able to provide a longer term stability of algorithm interfaces so that we can provide our users with some assurance that the work they do today won’t be undone tomorrow.</div><div class=""><br class=""></div><div class="">If the backend provider changes are causing our processing stuff to break, surely having some middleware in place to translate new backend interfaces to expose their inputs and results so that they function like the old interfaces on the user facing side of the algorithm should give us a way to deal with that?</div><div class=""><br class=""></div><div class="">Thanks for all the great work you guys are doing with processing, I don’t mean to detract from your efforts, only to lend a sense of user perspective to your planning.</div><div class=""><br class=""></div><div class="">Regards</div><div class=""><br class=""></div><div class="">Tim</div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><br class="">[0] <a href="https://github.com/qgis/QGIS/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aclosed+processing" class="">https://github.com/qgis/QGIS/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aclosed+processing</a><br class=""><br class=""><br class=""><br class=""><br class="">2016-03-08 8:53 GMT+02:00 Paolo Cavallini <cavallini@faunalia.it>:<br class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Hi Tim, Nyall,<br class="">while in principle I agree, I think this would be rather pointless in the<br class="">current situation.<br class="">Many algs break often anyway because of changes in the backends. My<br class="">suggestion:<br class="">" first put in place a complete set of tests<br class="">* only after that implement a versioning system<br class="">* provide clear instructions, possibly also tools, to help upgrading models<br class="">to new versions (only power users actually build models).<br class="">IMHO a current major stumbling block for users is the lack of documentation<br class="">for hundreds of algs, many of them quite obscure. Better address this first.<br class="">All the best.<br class=""><br class="">Il 7 marzo 2016 22:37:39 CET, Nyall Dawson <nyall.dawson@gmail.com> ha<br class="">scritto:<br class=""><blockquote type="cite" class=""><br class="">On 7 March 2016 at 19:13, Alexander Bruy <alexander.bruy@gmail.com> wrote:<br class=""><br class=""><blockquote type="cite" class="">1. Postpone such changes for next major QGIS release when API break is<br class="">allowed. In this case all existing scripts/models will work. But we<br class="">should live<br class="">with bugs and without some features, even if fix already available and<br class="">keep the<br class="">code of this fixes in sync with master until next major release.<br class=""></blockquote><br class=""><br class="">I honestly think 1 is the only valid approach here.<br class=""><br class="">I'll preface this opinion by saying that I HATE frozen API with a<br class="">passion. It makes development harder, slower and more expensive, and<br class="">prevents new features landing and bugs from being fixed [1]. With my<br class="">totally selfish developer hat on I'd love nothing more than for us to<br class="">adopt a non-frozen, do-whatever-the-heck-you-want API and with no<br class="">care<br class="">for compatibility with old projects ;)<br class=""><br class="">BUT<br class=""><br class="">The decision has been made for the project that QGIS has a frozen API<br class="">between major releases, and now that processing is part of the core<br class="">QGIS install it also needs to abide by that rule! Yes, it's a freaking<br class="">horrible PITA, but the alternative (breaking user's scripts and<br class="">models) is far worse for the project. And with my non-developer, QGIS<br class="">user hat on I would hate for scripts and models which I've invested<br class="">time into creating to get broken between releases.<br class=""><br class="">I'd suggest following the same approach as is taken by the c++ code:<br class="">make a versioned copy of the algorithm so that existing scripts/models<br class="">can still use the old version BUT it's not exposed anywhere in the GUI<br class="">and new models will transparently just use the new version. That's<br class="">what we've done for labelling (heck... even the old label engine is<br class="">STILL in QGIS on that extremely rare case that<br class="">someone opens a pre 2.0<br class="">project!), symbology, various composer items, etc. It results in<br class="">duplicate code and fills the codebase with a lot of deprecated cruft,<br class="">but that's the price of a frozen API :)<br class=""><br class="">Just my 2c! ;)<br class="">Nyall<br class=""><br class="">1. see https://github.com/qgis/qgis3.0_api/issues for a list of stuff<br class="">we CAN'T implement/fix until API is unfrozen<br class="">________________________________<br class=""><br class="">Qgis-developer mailing list<br class="">Qgis-developer@lists.osgeo.org<br class="">List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer<br class="">Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer<br class=""></blockquote><br class=""><br class="">--<br class="">Paolo Cavallini<br class="">www.faunalia.eu<br class=""></blockquote><br class=""><br class=""><br class="">-- <br class="">Alexander Bruy<br class="">_______________________________________________<br class="">Qgis-developer mailing list<br class="">Qgis-developer@lists.osgeo.org<br class="">List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer<br class="">Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer<br class=""></blockquote><br class=""><div class=""><span><img height="60" width="60" apple-inline="yes" id="5C7E9F48-C02B-4288-8D5D-B22B54C1BA83" apple-width="yes" apple-height="yes" src="cid:DDEF9B12-67C3-4498-BD7D-EC3563CC35A4" class=""></span><br class=""><br class=""><br class="">Tim Sutton<br class="">QGIS Project Steering Committee Member<br class=""><a href="mailto:tim@qgis.org" class="">tim@qgis.org</a><br class=""><br class=""><br class=""><br class=""></div><br class=""></div></body></html>