<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Feb 7, 2018 at 6:25 PM, Paolo Cavallini <span dir="ltr"><<a href="mailto:cavallini@faunalia.it" target="_blank">cavallini@faunalia.it</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_-5833473502297695778gmail-m_-7397762020155901698m_-8822521484772278695gmail-">Il 07/02/2018 11:18, Victor Olaya ha scritto:<br>
> I dont see the advantage in having providers in core.<br>
<br>
</span>I see the following:<br>
* tests (already available in our infrastructure)<br>
* translations<br>
* more exposure<br>
* documentation<br>
<span class="m_-5833473502297695778gmail-m_-7397762020155901698m_-8822521484772278695gmail-"><br>
> And if there is an<br>
> advantage, it's clearly not in how easy it is going to be to maintain<br>
> the plugin.<br>
<br>
</span>until now it has been maintained somehow; if more resources are needed,<br>
we can find a way<br>
<span class="m_-5833473502297695778gmail-m_-7397762020155901698m_-8822521484772278695gmail-"><br>
> If the people responsible of a given backend (like OTB) are<br>
> going to maintain it (which makes sense), why putting it in core where<br>
> they don't have write access?<br>
<br>
</span>why not granting them write access?<br></blockquote><div>That would still need users *waiting* for QGIS release for fix in algo is what I understood from other parts of discussion. </div><div>I don't know what these developers are going to do with a bugfix after a new release. That's some kind of mystery unsolved to me.<br></div><div>I hope there will be zero bugs after releases.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="m_-5833473502297695778gmail-m_-7397762020155901698m_-8822521484772278695gmail-"><br>
> Better in a separate repo. Also, they can<br>
> release whenever there are changes, without having to wait for a new<br>
> release. That way, the plugin will always be in sync with new releases<br>
> of the backend app.<br>
<br>
</span>this is certainly true; AFAICT OTB people has proposed a solution</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="m_-5833473502297695778gmail-m_-7397762020155901698m_-8822521484772278695gmail-"><br>
> If we put them in core...why putting only this big ones (which in some<br>
> cases require installing external apps manually by the user), and not<br>
> put other plugins that exist and contain Processing providers? <br>
<br>
</span>I'd be in favour of adding anything important for users.<br>
<br>
Thanks for your thoughts.<br>
<br>
When in Madeira we can have a discussion about this. It would be good if<br>
all interested parties could meet, locally and remotely.<br>
<div class="m_-5833473502297695778gmail-m_-7397762020155901698m_-8822521484772278695gmail-HOEnZb"><div class="m_-5833473502297695778gmail-m_-7397762020155901698m_-8822521484772278695gmail-h5"><br>
All the best.<br>
--<br>
Paolo Cavallini - <a href="http://www.faunalia.eu" rel="noreferrer" target="_blank">www.faunalia.eu</a><br>
QGIS & PostGIS courses: <a href="http://www.faunalia.eu/training.html" rel="noreferrer" target="_blank">http://www.faunalia.eu/trainin<wbr>g.html</a><br>
<a href="https://www.google.com/trends/explore?date=all&geo=IT&q=qgis,arcgis" rel="noreferrer" target="_blank">https://www.google.com/trends/<wbr>explore?date=all&geo=IT&q=qgis<wbr>,arcgis</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="m_-5833473502297695778gmail-m_-7397762020155901698m_-8822521484772278695gmail_signature"><div><font face="arial, helvetica, sans-serif">Regards,<br>   Rashad</font></div></div>
</div></div>