On 1 April 2017 at 02:09, Kevin Kofler <kevin.kof...@chello.at> wrote:
> Nonsense. Nobody is going to mark up each and every use of a smart pointer > with some warning pragma, that just does not make sense. > > Warnings are optional by design, you cannot dictate a distribution-wide > policy for them. > What I wrote was not distribution-wide proposition. It was direct reply to your doubts about enable display those warnings due official distro packages build process. As you just wrote those warnings are optional and during such process chosen option should be "display everything what is possible". Why? Because packagers may chose during packages development process to display output without those warnings to focus on "packetology". However at least in one central point where all packages are build should be possible to build many packages in context of exactly the same set conditions which will allow produce set of metrics holding number and warnings types distribution. Exact numeric data from those metrics may be correlated to - general project code quality - general direction of the changes code quality which will be correlated with to changes of those numbers - may expose as well new issues or with compiler when exactly the same version of the code compiled when exactly the same source code suddenly may start produce new warnings - sometimes changes of number of warnings will be exposing issues within header files installed on the system used during compilation As you see collecting those metrics data allows make completely new set of observations which may be not possible to catch when packager A time to time is building packages which he/she maintains. Regression test based on only comparing numbers from those metrics will be kind of early alarms about "possibly something is wrong". In other words to suck such types informations out of those warnings you don't need sophisticated machinery processing straight build logs. All what is needed here is set of dumb/primitive counters. Processing will be only with using comparing numbers out of those counters. To draw some presentation layer "picture" less important is *how many* exact warnings is producing package A and or population of packages but *how* those numbers are changing on time scale and context of those changes around exact single packages if in exact period of time was package A compiled multiple times out of exactly the same version of the package A source code. Just to be correctly understood. I'm not asking to drop everything and implement above NOW. NO!!! I'm trying to tell only that by taking care of some set of trivial problems in the future will be possible to produce such metrics data in "clean laboratory conditions" or as a result of "aligning all packages in formation". This will allow to spot in first stage some set unregular/problematic/pathological packages to make next step(s) decisions. This definitely could be longer process but consisting from relatively simple to control steps. kloczek -- Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>*
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
