<p dir="ltr"><br>
On 23 Dec 2014 5:11 am, "Paolo Cavallini" <<a href="mailto:cavallini@faunalia.it">cavallini@faunalia.it</a>> wrote:<br>
><br>
> -----BEGIN PGP SIGNED MESSAGE-----<br>
> Hash: SHA1<br>
><br>
> Hi all.<br>
><br>
> Il 22/12/2014 15:04, Sandro Santilli ha scritto:<br>
><br>
> > The rotation functionality might be reported as not being complete<br>
> > in the GUI allowing for enabling it.<br>
> ><br>
> > Of course I'd prefer having all things working, but I just could<br>
> > not raise enough funding for everything, and delegating the work<br>
> > done so far in a PR might make it hard for anyone else (not just<br>
> > me) to find more to build upon what we have now.<br>
><br>
> IMHO removing the function will make much more difficult to attract<br>
> interest and funding to complete the necessary features. My proposal:<br>
> add an option to add the rotation spinbox, deactivated by default, and<br>
> clearly marked as experimental/incomplete. In this way, only<br>
> interested and conscious people will activate it, if they are ready to<br>
> bear the missing parts.</p>
<p dir="ltr">I disagree - while there may be an issue with the difficulty of getting wide testing of pull requests, the solution isn't to allow broken code into master.</p>
<p dir="ltr">We've recently made great progress in showing that we are a serious enterprise ready alternative, with the introduction of CI testing and the proposals for LTS releases. We now need to show that we are serious about the quality of our code and product by not allowing broken or beta features into releases. Adding a checkbox to unlock such features isn't a good solution - it just looks amateurish and hacky!</p>
<p dir="ltr">As it stands right now, what is the use of this feature? It can't be used for presentation (no composer support) nor for analysis or querying use (broken selection and info tools). Without addressing these issues this feature has no current use case (I may be missing something here, feel free to fill me in if I am). Sandro has made it clear that he currently has no plans for tackling these issues before our next release - meaning either:<br>
1. Our first LTS release will be left with a broken, buggy feature, which is not a good impression at all for users and sponsors.<br>
Or,<br>
2. Someone else will have to volunteer their time to fix this code before release.</p>
<p dir="ltr">This is a big decision, as it has the potential to set the precedence for how QGIS is developed. Do we allow work-in-progress and incomplete features in master, or should they be left in branches and pull requests until they are complete and largely bug free?</p>
<p dir="ltr">Personally, I'm strongly in favour of the second option.</p>
<p dir="ltr">Nyall</p>