Hi all,
So there seems to be a general agreement to invest more into quality/bug
fixing/testing - but not so much about the release frequency.
-----------------------------------
I'd like to mention some more reasons for fewer releases:
* the plugins: plugin authors are more likely to test and fix their
plugin for a new release if it isn't released every 4 months. We often
have the case that if a user updates to a new version, that their
favourite plugin that they need may be broken and they'll have to wait
several weeks until the author can fix it
* same applies for inhouse plugins that organizations maintain for
themselves
* training material, documentation and books - have a hard time keeping
up. If you are lucky, you'll get a book that covers 2.6 or 2.8.
* the general perception for QGIS users that they are always many
versions behind - don't you think it is kind of frustrating for our
users to be always several releases behind - because they need to rely
on older versions? I remember many email threads where users have
described a problem and we tell them that is fixed in master - what does
it help them, if they are on the older version and supposed to use the
LTR release in a production environment?
* testing: as I said - I believe you will get more/better testing if we
slow down
Thanks,
Andreas
On 13.10.2015 09:28, Paolo Cavallini wrote:
Il 13/10/2015 09:09, Andreas Neumann ha scritto:
Hi all,
Thanks all for joining the discussion.
My main concern, is about quality, not so much about the exact number of
months between the releases - and I have the impression that given the
current situation (not enough test coverage, large parts of the codebase
untested, still large chunk of code go into master without
QGEP/discussion/cross review) - that we cannot deliver good quality with
such a rapid pace.
Hi Andreas,
I agree with you, I think you touched very important points for our
future. We discussed about this in the past, but now IMHO we are in a
much better position, because we can think of QGIS as essentially
feature complete (OK, we are never complete, but most people can do
almost all they need even with the "oldish" LTR).
So slowing down the pace of new features, and shifting the attention to
more quality, is now more feasible than ever.
This could be done being more rigid about acceptance of new features, e.g.:
* always request a QEP with a proper discussion before merging (open
questions: possibly also a vote? a consensus? by the community or by the
PSC?)
* only accept code with proper test coverage, and leave it pending until
it has it.
However, ultimately the issue is about resources: we should be able to
communicate our [enterprise|large|power] users that investing in code
quality is good for them. IMHO, with a couple of developers paid full
time for this, things will improve dramatically; without that, we'll
struggle. And all this regardless of the frequency of releases.
All the best.
_______________________________________________
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
