On 05.02.2020 11:50, Edward Welbourne wrote: > Jani Heikkinen (5 February 2020 06:42) >> Why this is so important that we should get the exception & go in after FF? > Do we allow changes approved before feature freeze to get past the Coin > hurdle, even if that happens after FF ? How much fixing of the change > (if it turns out to have problems integrating) is acceptable, before we > declare that it's no longer the change that was approved in time ?
If the change is ready and approved by the time of feature freeze and only delayed by CI problems, failures from other changes in a batch, or the awkwardness of our dependency structure, I think it has to be acceptable to merge after the freeze. Otherwise feature freeze becomes a lottery where the features in a given release is based mostly on chance. The slack to accommodate these intrinsic delays need to be in the release plan in my opinion, and not in each developer's individual plan for merging their changes. If it turns out the change cannot be merged as-is and needs additional fixing, I think it should be addressed as any other change that doesn't match the conditions above: on a case-by-case basis, considering value vs. risk in each case. In the particular case you mention, I think we should fix the issues with the feature in 5.15 rather than revert it. The reason we have several months between freeze and release is so that we have time for stabilization work such as this. -- Eskil Abrahamsen Blomfeldt Senior Manager, Graphics The Qt Company Sandakerveien 116 0484, Oslo, Norway eskil.abrahamsen-blomfe...@qt.io +47 938 85 836 http://qt.io https://twitter.com/eskilblomfeldt The Future is Written with Qt _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
