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" <[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
_______________________________________________
Qgis-developer mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
