While discussing in IRC how we could improve our procedures and reduce
audit problems we hit on the issue of wide-ranging code cleanup or API
conversion patches/"projects".
The distinguishing factors for flag-day changes is that they are a)
large, b) essentially not changing logics in new ways ("polish" or
"cleanup" patches), and c) variously painful for everyone merging into
their incomplete work.
Some examples of these that we know of are:
* removal of HERE macro
* removal of some AsyncCall wrappers (ie CommCalls)
* removal of .cci files
* removal of _SQUID_INLINE_
* multiple cases of Squid-3 coding guidelines renamings
* SourceLayout shuffling actions (not the API cleanup)
* removal of defines.h and/or all shufflings out of there
* removal of typedefs.h and/or all shufflings out of there
* removal of structs.h and/or all shufflings out of there
* C++11 "Rule of Five" compliance check/update
* several C++11 syntax upgrades changes once -std=c++11 is required
* possible replacement for debugs() API
* astyle version upgrade
When a change can it should avoid being a flag-day. But if breaking into
a set of smaller incremental changes is difficult or causes too much
annoyance from repeated painful merges or wastes audit time on other
patches, then it seems better to end the ongoing pain with a flag-day
commit.
I propose that we dedicate a 5-day period in the Squid release cycle
when these types of patches are accepted into trunk. Accumulating a list
of proposals like above until the period occurs.
* From the release perspective the week or two prior to branching trunk
seems to be the best time for these to occur. During that period new
feature and logic commits to trunk are usually heldup in audit we are
trying to ensure a stable first beta. We also have minimal pressure/need
for back-porting patches across the change to already stable branches by
then.
* 5 days because its a waste of time to write these very long in advance
and we may want a short period to ensure stability is retained. Also the
exact branching day is not predictable very long in advance.
* audit requirements are small. Just checking the patch is restricted to
pre-agreed painful act(s) and has no other code changes.
I also propose that this type of patch audit submission be accompanied
by clear how-to steps assisting porters of older code to get over the bump.
For example, when we initiated astyle use globally I have provided
details of how to merge all previous revno from trunk, how to merge the
painful rev dropping rejects and run the script on new code manually. A
simple process instead of painful fiddling with individual patch rejects
which the unwary would be faced with.
NP: if we can't provide a simple how-to then re-consider the patch
suitability for being a flag-day change.
Amos
