Re: [RFC] flag day commits
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
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
Re: [RFC] flag day commits
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
