On 16 June 2015 at 21:54, Matthias Kuhn matth...@opengis.ch wrote:
In the quest for an always closer-to-perfection state of code, some
goblins tried to get the warning count (on gcc and clang) yesterday as
close to zero as possible. This was done in order to allow you (as a
developer) to see
On 06/22/2015 02:03 PM, Nyall Dawson wrote:
On 16 June 2015 at 21:54, Matthias Kuhn matth...@opengis.ch wrote:
In the quest for an always closer-to-perfection state of code, some
goblins tried to get the warning count (on gcc and clang) yesterday as
close to zero as possible. This was done
On Tue, Jun 16, 2015 at 02:27:10PM +0200, Matthias Kuhn wrote:
In an ideal world, all internal code would be ported to the new API and
some tests guarantee that the legacy API keeps working as expected.
Sometimes it may also be ok to leave internal code use the deprecated
API. It just has to
On 06/16/2015 02:03 PM, Sandro Santilli wrote:
On Tue, Jun 16, 2015 at 01:54:34PM +0200, Matthias Kuhn wrote:
The plan is to let travis test for warnings and if there are warnings
mark the build red. With this in place, an author of a commit will be
required to spend some thoughts on a
On Tue, Jun 16, 2015 at 01:54:34PM +0200, Matthias Kuhn wrote:
The plan is to let travis test for warnings and if there are warnings
mark the build red. With this in place, an author of a commit will be
required to spend some thoughts on a warning and take care of it before
merging into
In the quest for an always closer-to-perfection state of code, some
goblins tried to get the warning count (on gcc and clang) yesterday as
close to zero as possible. This was done in order to allow you (as a
developer) to see if your code changes cause warnings without scrolling
through heaps of
