On Mon, Aug 19, 2013 at 4:47 PM, Thiago Macieira <[email protected]> wrote: > On segunda-feira, 19 de agosto de 2013 15:40:06, Alan Alpert wrote: >> > 2) -Werror is enabled only for certain compiler versions. I'll update the >> > whitelist to have an upper range too. For example, right now it enables - >> > Werror for GCC 4.6 and above. I'm going to introduce an upper limit >> > because we don't know what new warnings our code triggers with newer >> > versions of GCC. That means we'll need to first clean up the warnings >> > before expanding the whitelist. >> >> How is this "clean up" to be managed? The scenario I'm envisioning is >> that warnings are cleaned up inside qtbase, allowing the change to >> pass CI, while a new warning appears in another module which is then >> broken by the qtbase change. We might need to integrate qt5.git >> merging into the whitelist expansion test somehow, or provide another >> solution so that all modules are checked before updating the >> whitelist. > > Someone or a group of people fixes all the warnings with a given new compiler > version in all modules. Once all changes are in, past the CI and possibly past > a qt5.git integration, we expand the whitelist in qtbase. > > Worst case scenario, there's a race condition with new code that introduces a > new warning.
Given how long CI integrations can take I would not be surprised to see such a race condition occur. But so long as "all modules" is explicitly in the process (and we can't think of a good automated test for it) I can accept that risk. -- Alan Alpert _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
