> We have a lot of significant features that have or will land soon and our > experience suggests that those merges usually bring their set of > instabilities. The goal of the proposal was to make sure that we get rid of > them before TCM and Accord land to allow us to more easily identify the > root causes of problems.
Agree with Benjamin that testing in phases, i.e. separate periods of time, has positives that we can take advantage of. a) do we have test failures on circle on trunk right now, and > b) do we have regressions on trunk on ASF CI compared to 4.1 > > Whether or not new features land near the cutoff date or not shouldn't > impact the above right? > I don't think it can be limited to the above. They are our minimum requirements to getting to beta, to rc, and to GA. But in practice we wait and receive bug reports from downstream testing efforts. Such testing isn't necessarily possible pre-commit, e.g. third-party and not feasible to continuously run, nor appropriate to upstream/open-source. We want GA releases to be production ready for any cluster at any scale. So I guess in practice for us Stable Trunk != GA, but that's ok – just being honest to the ideal we are moving towards.
