Re: [RFC] flag day commits

sön 2014-06-08 klockan 23:05 +1200 skrev Amos Jeffries:

> 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.

Breaking a flag-day commit into smaller changes do not avoid it being a
flag-day commit. This type of changes has to be viewed in it's entire
scope, not individual commits.

The exception is if the change can be done in two steps where the first
step prepares for the change and allows new code to use new agreed
style, leaving the change of existing code for flag-day commit. But only
if there is some users of the new way.

This gives the flow

1. Preparation change
2. First user(s)
3. Cleanup of old code to use the new way.
4. Removal of any glue supporting old code.

There 1 & 2 can be committed during normal feature window, while 3
should wait until the next flag-day window, and 4 might even be
requested to wait one cycle longer.

If possible it's preferred if 3 can be scripted.

I would also recommend that 4 is from start guarded by a define in step
1, allowing easy compile time check that code is really using the new
style.

> * 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.

There should be sufficient cool-down period between these and first
beta.

Technically the flag day do not need to be strictly connected to release
cycle. Might be anytime while trunk is open.

> * audit requirements are small. Just checking the patch is restricted to
> pre-agreed painful act(s) and has no other code changes.

The change should have gone thru full review prior to being accepted as
a flag-day change.

> 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.

Yes.

> NP: if we can't provide a simple how-to then re-consider the patch
> suitability for being a flag-day change.

Yes.

Regards
Henrik
Received on Mon Jun 09 2014 - 06:56:39 MDT