FWIW, I agree with a lot of things Henrik is saying below. The most important ones, for me, are:
* A change designated for a flag-day commit only adds certain procedures/responsibilities/requirements. It does not remove any of the key established requirements for a change to get accepted. Thus, getting a change accepted in the first place is still necessary. That means, among other things, convincing others that the change does more good than harm. For example, just removing all HEREs does more harm than good IMO, regardless of how it is committed (during a "flag day" or not). * The focus should be on minimizing code porting/maintenance harm. Designating a special day to do a lot of harm does not help much. On the other hand, having a script that can automatically apply the change to any branch is very helpful and can tilt the harm/good balance. Also, most of the posted examples of "flag day" changes do not need a special flag day IMO (and some should not happen at all). Thank you, Alex. On 06/09/2014 12:56 AM, Henrik Nordström wrote: > 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 >
