Hi,
I'd extend the window to one calendar week, but apart from that it
all seems very reasonable.
On Sun, Jun 8, 2014 at 1:05 PM, Amos Jeffries <squ...@treenet.co.nz> wrote:
> 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
--
Francesco
