I agree for separating commits we can have multiple commits that firstly add the new parameters and decorators, and later replace current decorators with new decorators which are well unit tested.
However, it makes no sense we have two codepaths from FlinkKubeClient to decorators since these two version of decorators are not api compatible and there is no reason we keep both of them. Best, tison. Yang Wang <danrtsey...@gmail.com> 于2020年2月25日周二 下午7:50写道： > I think if we could, splitting into as many PRs as possible is good. Maybe > we could > introduce the new designed decorators and parameter parser first, and > leave the existing > decorators as legacy. Once all the new decorators is ready and well > tested, we could > remove the legacy codes and use the new decorators in the kube client > implementation. > > > Best, > Yang > > Canbin Zheng <felixzhen...@gmail.com> 于2020年2月25日周二 下午6:16写道： > >> Hi, Till, >> >> Great thanks for your advice, I totally agree with you to split the >> changes up in as many PRs as possible. The part of "Parameter Parser" is >> trivial so that we prefer to make one PR to avoid adapting a lot of pieces >> of code that would be deleted immediately with the following decorator >> refactoring PR. Actually I won't insist on one PR, could it be possible >> that I first try out with one PR and let the committers help assess whether >> it is necessary to split the changes into several PRs? Kindly expect to >> see your reply. >> >
