[Qgis-psc] On finances

[Nyall Dawson]

On Mon, 3 Dec 2018 at 23:12, Tim Sutton <tim at kartoza.com> wrote:

>  The only way out I can see is to a) get stricter about accepting code that lacks tests and b) invest an equal amount in unit test development that we can catch bugs before they enter the code base….

I've been one of the strongest campaigners for more unit tests in the
past, but in this case, I don't believe it's the problem anymore.

QGIS devs now have a innate culture that unit tests are just a "part
of business as usual", and it's EXTREMELY rare to see a pull request
today without any unit tests included. While it's an easy answer to
cry "more unit tests" -- I honestly don't see how we COULD do more
than we already do. The unit testing battle has already been won --
we've a library of thousands and thousands of tests, with very good
test coverage of the core QGIS functionality.

Furthermore, we already have a culture where PRs are the norm, and
again, it's extremely rare to see any feature or bug fixes pushed
directly to master without it going through the PR review process.

This is a really good thing... the culture shift happened just from
some motivated developers (credit to Oslandia here, the culture shift
really was a result of their efforts) leading by example instead of a
fixed policy change. And now it's the norm, and I know most QGIS
developers feel guilty if they break from this in some way ;)


So unfortunately, that doesn't leave us with any easy answers here. My
2c would be that it comes down to wider USER testing of the
prereleases, and maybe a compulsory "hard freeze" period before the
final releases are packaged. At least, the major regressions that I'm
aware of from 3.4 would never have been covered by unit tests, even if
we spent years solely writing tests and nothing else. They were simply
too dependant on platform specific issues and app level UI
functionality.

Nyall