I agree with Nyall. I think putting hidden "proof of concepts" within an official release doesn't put QGIS in a good light. It could be ok some time ago, when QGIS was a niche, but not today. If a sponsorship campagin is required to complete the development we should pursue different marketing strategies (e.g. blogs, videos showing the upcoming features).
giovanni 2014-12-22 23:47 GMT+01:00 Nyall Dawson <[email protected]>: > Sorry, gmail messed up my original reply: > > On 23 Dec 2014 5:11 am, "Paolo Cavallini" <[email protected]> wrote: > > > > IMHO removing the function will make much more difficult to attract > > interest and funding to complete the necessary features. My proposal: > > add an option to add the rotation spinbox, deactivated by default, and > > clearly marked as experimental/incomplete. In this way, only > > interested and conscious people will activate it, if they are ready to > > bear the missing parts. > > 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. > > 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! > > 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: > 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. > Or, > 2. Someone else will have to volunteer their time to fix this code before > release. > > 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? > > Personally, I'm strongly in favour of the second option. > > Nyall > > _______________________________________________ > Qgis-developer mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/qgis-developer > -- Giovanni Allegri http://about.me/giovanniallegri Twitter: https://twitter.com/_giohappy_ blog: http://blog.spaziogis.it GEO+ geomatica in Italia http://bit.ly/GEOplus
_______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
