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.
The only other software I know that has such a rapid pace of releases
are web browsers (Google Chrome and Firefox) - but these projects have
rather small incremental changes in between their releases and very
rigid requirements for new additions to the code base, and large and
comprehensive test suites. In addition they have automatic updates and
much more financial resources than we have.
We can't build on the above things (at least not yet). In our current
situation we have to rely more on manual user testing - and for that the
one month testing/bug fixing phase is too short. And again - for someone
who wants to test all of the releases - the releases happen too often.
What's the point of releases where people don't have the time and
resources to test them in depth - and the time to properly react on
findings?
-------------------------------
The other thing is our long list of open bugs. I also regard many of the
"normal" bugs as severe or at least very annoying.
For me we should take the time to have a break in feature development
and invest more in quality - and having a slightly slower release
schedule gives us at least a chance to do more in this respect.
We have some very good initiatives in this respect: the LTR release, the
paid bug fixing, more donations, more tests provided, processing test
suite will start soon, investment in documentation, etc. I am just
asking for a slower pace to do these things properly.
Andreas
On 13.10.2015 08:46, Paolo Cavallini wrote:
Hi all,
Il 13/10/2015 01:14, Tom Chadwin ha scritto:
If the devs need more end users to test, then changing to a release every
six months, LTR every two years, would help. However, how would the devs
feel about patching LTRs for twice the duration they do now, and for one
extra non-LTR in between each? To me it sounds like significantly more work
to keep backporting for two years instead of one.
the current LTR has been an experiment, and IMHO it has been a success.
Do we really want to change schedule every 6 months?
We know for sure there are contrasting needs, and we'll never make
everyone happy. Some times ago, we had people complaining not being able
to use for many months the supercool feature they have developed or paid
for.
I think it's mostly a matter of communicating appropriately:
* for maximum reliability, use the LTR
* if you need latest features, go for the latest published.
Maybe we should state this clearly on the download page.
On the other hand, I am with Nyall on the Qt5 (and I should add Python
3) issue.
More below.
Il 12/10/2015 23:17, Larry Shaffer ha scritto:
At Boundless we are seeing both sides of the issue: users who want only
the LTR and users who deploy the LTR but always work with or test the
latest version between deployments of the LTR. The latter group is
finding the current pace quite difficult to keep up with. I'm talking
about very large government agencies rolling out to 100s upon 100s of
thousands of users. They rely upon the advice of their power users who
are working with whatever is the current version (not just the LTR).
This touches a *very* imprtant point: large organisations should have
very clear that if they need a more stable release cycle, the best and
most clever thing they should do is to fund:
* more automated tests
* more backfixing
* more and earlier backporting.
I cannot believe someone using any software in such huge numbers not
having a few hundreds thousands bucks to properly support these needs.
All the best.
_______________________________________________
Qgis-developer mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
