On Wed, Jun 24, 2020, 10:56 AM Gregory Nutt <spudan...@gmail.com> wrote
> > My concern is that if we sweep things under the carpet now and continue > with the 9.1 eyes shut as if there is nothing wrong, we will continue to > degrade the OS footprint over time. It requires aggressive action to > control the binary size! > > The PR-induced bloat due to the NSH 'date' command configuration was > added between 9.0 and 9.1. That was apps/ commit > 4adb83c754500cfebe4c24a498eb4139e3ff8866, dated April 7. It is on > master but not in the releases/9.0 branch. Apparently it just missed > the cut-off for 9.0 but is included in 9.1. > > The CONFIG_TIME_EXTENDED change is, I believe, pre-9.0 and so does not > have as strong an argument in the current context. But I think any > size-related fixes that do not introduce other issues or cause loss of > functionality are good game for reversion. > > We need to stop the practice of changing settings by changing their > default values. That has ramifications that are too extensive and too > unpredictable! And we need to stop removing size reducing configuration > options without strong argument. In the case of the > CONFIG_TIME_EXTENDED, the argument is that the default selection makes > the structure non-compliant with POSIX requirements. That is a > reasonable argument. There is no good argument of any kind for the NSH > 'date' command change, however. That change should certainly be removed. > Ok let's go ahead and plan to do an RC1. What I ask is that people really try to get some testing in. So we can address this prior to cutting releases. That 9.1 branch that this was made off of has been static besides the release notes for almost 10 days. It took calling a vote to find this issue. I do appreciate the testing that people have done! Can we plan to cut RC1 on Friday or do people want to wait longer? After Monday I'll be likely somewhat unavailable for a few days so I may be slower to respond to moving the release process forward. --Brennan
