<div dir="ltr"><div>Dear Borys,</div><div><br></div><div>for our plugin (the OpenQuake Integrated Risk Modelling Toolkit [1]) we</div><div>have been very happy to use the "experimental" flag so far, and we consider it</div><div>a very useful feature.</div><div><br></div><div>For us, the ideal workflow would be to release a new</div><div>version of the plugin flagged as experimental, then let our scientific team try</div><div>it extensively on real use-cases, and then mark it as stable. If I understand</div><div>correctly, your proposal is to remove the possibility to mark an existing experimental</div><div>version as stable, so we would have to release an identical version of the plugin</div><div>without the "experimental" flag, as soon as we receive the approval from our</div><div>scientists.</div><div><br></div><div>From a user perspective, we believe it is important that the user</div><div>can actually trust our plugin for "production" purposes, as long as the plugin</div><div>is not flagged as "experimental". Users that are willing to try new</div><div>cutting-edge features at their own risk, can still enable experimental plugins</div><div>and download the most recent version.</div><div><br></div><div>We also have another important point in favor of keeping two different versions</div><div>of the plugin. Our tool has to interface itself with the OpenQuake Engine [2],</div><div>that is a scientific engine that evolves very quickly. We currently keep the</div><div>most recent stable version of our plugin aligned with the latest official</div><div>release of the OpenQuake Engine, ensuring compatibility between the two</div><div>softwares. Between one official release and the next one, we release new</div><div>experimental versions of the plugin, ensuring compatibility with the nightly</div><div>builds of the OpenQuake Engine. Therefore, scientists that are interested in</div><div>using the most recent features offered by the two softwares can rely on the</div><div>nightly builds of the OpenQuake Engine and on the latest experimental OpenQuake</div><div>Integrated Risk Modelling Toolkit.</div><div><br></div><div>For the above reasons, our answer to your question is yes, we do really need</div><div>this feature. And if you decide to drop it, we will have to significantly</div><div>redesign our release workflow.</div><div><br></div><div>Paolo Tormene, on behalf of the OpenQuake Team </div><div><br></div><div>[1] <a href="https://plugins.qgis.org/plugins/svir/" target="_blank">https://plugins.qgis.org/plugins/svir/</a></div><div>[2] <a href="https://github.com/gem/oq-engine/" target="_blank">https://github.com/gem/oq-engine/</a></div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, Aug 26, 2018 at 8:11 PM Borys Jurgiel <<a href="mailto:lists@borysjurgiel.pl">lists@borysjurgiel.pl</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Lists,<br>
<br>
Before I make a QEP I'd like to know your general thoughts.<br>
<br>
After I removed the deprecated plugins filter from the Plugin manager (and <br>
make them always visible) [1], Alex suggested doing the same with the <br>
Experimental status.<br>
<br>
Initially it was designed for two cases: to mark a whole plugin as <br>
experimental, and to just mark the recent version (so a kind of beta). Both <br>
cases seem to be popular among authors: at the moment we have 215 plugins for <br>
master, from which ~40 are experimental only and ~20 are in both versions.<br>
<br>
However, I'm not sure if it makes much sense nowadays. Releasing 'stable' and <br>
'experimental' versions seems a bit overscaled to me. And there is a simpler <br>
solution: If the recent version is buggy, users can just download the last <br>
working one from the repo and install from zip. The former case, when the <br>
whole plugin is experimental, seems to be often misused: authors can use it to <br>
hide some specialised of localised plugisn from majority of users. In fact <br>
even I committed such clear misuse, marking the Plugin Reloader as <br>
experimental just to not clutter the list for normal users... Another reason <br>
could be a shyness. But again, we have the rating stars now and don't need to <br>
rely on the author's shyness anymore.<br>
<br>
So... Do you see important reasons to keep this tag? Maybe we should <br>
completely drop it? Or just remove the option to hide them from manager, <br>
leaving the flask icon on the plugin details page?<br>
<br>
Regards,<br>
Borys<br>
<br>
[1] <a href="https://github.com/qgis/QGIS/pull/7713" rel="noreferrer" target="_blank">https://github.com/qgis/QGIS/pull/7713</a><br>
<br>
<br>
<br>
_______________________________________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><br>
<span><strong>PAOLO TORMENE</strong> </span>
<span> senior software developer </span>
+39 0382 5169882
<br>
<div> </div>
<strong>GLOBAL EARTHQUAKE MODEL </strong>
working together to assess risk
<br>
<div> </div>
<span><strong>GEM -</strong>
<a href="http://www.globalquakemodel.org" target="_blank">globalquakemodel.org</a> </span>
<span><strong>T -</strong>
<a href="http://twitter.com/GEMwrld" target="_blank">@GEMwrld</a> </span>
<strong>F -</strong>
<a href="http://www.facebook.com/GEMwrld" target="_blank">GEMwrld</a> <br></div></div>