On Tue Dec 23 2014 at 8:57:26 AM G. Allegri <[email protected]> wrote:
> 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
_______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
