[squid-dev] find-bad-changes.pl

[Amos Jeffries]

On 22/08/2015 12:44 p.m., Alex Rousskov wrote:
> On 08/21/2015 10:47 AM, Kinkie wrote:
> 
>> This is in fact what I have tried to - sometimes not to the letter,
>> unfortunately, and I'm sorry for that.
> 
> FWIW, the attached quick-and-dirty find-bad-changes.pl script detects
> some offending patch changes, but it is not 100% accurate and is not
> meant to replace a human developer examining the patch before posting.
> 

Thank you.

> Please note that the script outputs a weird combination of source code
> file name and patch file line number as a GCC-style red flag line
> address. This should probably be changed to use the patch file name
> (while providing the source code file name elsewhere).
> 
> For your particular patch, the script raises only 6 red flags. Here are
> _unaudited_ results for a few recently posted patches:
> 
>> mempools-nozero-v2.patch: red flags: 22
>> PackableStream_mk5.patch: red flags: 3
>> PayloadFormatter_mk3-2.patch: red flags: 0
>> SQUID-99-truncate-aborted-resp-bodies-t6-1.patch: red flags: 0
>> coverity-fixes-4-v2.patch: red flags: 6
> 

We agreed to change these things when the line itself *or the code
around it* was being changed. So the whole hunk changed as a
design-change unit instead of two or more patches.
 In my audit I allowed polishing where the function/method was short or
the line was between two other code changes.


I still believe we need to do these as flag-day in trunk just before
branching a new version.

Once those are over we face a LOT less wasted time arguing and auditing
around them. As it stands we face the pain from 2011 to X+10 from
whatever future date X any given line is changed. We could have been
halfway over that long-tail portion of HERE by now, with only the very
oldest version backports being an issue. And only an issue for those who
are actively *paid* to do those ancient ports (plus me), not submission
pain lumped on all the volunters trying to work with current versions.

Where the code design itself has changed the patch needs a re-write
anyway and polishing hunks are insignificant against that.

Where the code design has not changed the portage part of pain is still
the smallest part. Just a few hunks that bzr puts in the wrong location
and needs seconds/minutes manually moving. bzr itself takes care of the
hunk locations just fine. That is the kind of "pain" that IMO is better
to have at a fixed known location (version boundary), which can be
noted, than to have occuring on every portage attempt to any version.

3.5 -> 4 is a better place for flag-days then other versinos have been,
since I/we have to rebuild 3.5 on every backport with -std=c++98 anyway
just to make sure nothing kills it at the language level. Its already a
pre-marked pain point for better reasons than polish.


Amos