[Qgis-developer] Ugly jumping maps while zooming

[Andreas Neumann]

Hi,

I agree with Nyall. We need to be more strict with new features - if 
they break other functionality. That's why we added the testing 
integration. I value the work Sandro has done - but if it can't be 
finished we need to roll it back and develop in a separate branch. There 
are too many side effects - and combined with the fact that there is not 
enough time/funding it seems too risky for me to include it in master.

If we don't stick to a stricter QA and LTS we will loose credibility and 
organizations who already use QGIS in a production environment will run 
into troubles.

Andreas



Am 2014-12-22 23:47, schrieb Nyall Dawson:
> Sorry, gmail messed up my original reply:
> 
> On 23 Dec 2014 5:11 am, "Paolo Cavallini" <cavallini at faunalia.it>
> 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
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer