[Qgis-developer] Ugly jumping maps while zooming
nyall.dawson at gmail.com
Mon Dec 22 14:40:59 PST 2014
On 23 Dec 2014 5:11 am, "Paolo Cavallini" <cavallini at faunalia.it> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Hi all.
> Il 22/12/2014 15:04, Sandro Santilli ha scritto:
> > The rotation functionality might be reported as not being complete
> > in the GUI allowing for enabling it.
> > Of course I'd prefer having all things working, but I just could
> > not raise enough funding for everything, and delegating the work
> > done so far in a PR might make it hard for anyone else (not just
> > me) to find more to build upon what we have now.
> 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
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.
2. Someone else will have to volunteer their time to fix this code before
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Qgis-developer