On Mon, Jan 13, 2020 at 8:32 AM Gregory Nutt <spudan...@gmail.com> wrote: > > > > > >> So I guess our choices are: > >> > >> 1. Reinstate (void) only where the warning occurs. > >> > >> 2. Reinstate (void) everywhere return values aren't checked. What a > >> nightmare. > >> > >> 3. Change defines such as the above to static inline functions. > >> Disadvantage: The inline keyword is not in the C89 standard. > > > > I have ran the build tests and do not know of any other cases like > > this. Certainly, a few more might show up but it is not an endemic > > problem at the moment. > > > > At its worst, it is only a warning. > > The real problem here is not really that we may (or may not have) opened > up a bunch of new warnings. The issue here is that our QA process > sucks. We make enormous changes like this and commit it to master > without so little as verifying that the code compiles and or that it > builds without introducing new warnings. The code is just changed and > "thrown over the fence." > > This is total unprofessional and must come to a stop. The way to bring > this to a stop is to complete the workflow definition and the > implementation of some nightly builld-everything step that has to happen > before any PR is committed. The fix is to improve our QA processes so > that this cannot happen. > > But we have, apparently, lost interest in the workflow. Apparently, > Haitao Liu is working on something, but that is a black box. We have no > visibility of what is happening, what is being done in detail, when it > will be rolled out, or how it integrates with the unfinished workflow. >
Haitao is trying to create the jenkins job which will run all builtin config: any build error either get fixed or config should be remove from repo. The integration is simple: each commit MUST pass the build check before it can merge into mainline. > Greg > > >
