I am strongly against early integration, because we can't / don't remove things when we should. MVs are the prime example here, as is the current iteration of Vector search.
Early integration works fine when it's internal software that you have control over, it doesn't work well for software that gets deployed and relied on outside your org. On Mon, Dec 9, 2024 at 2:02 PM Dinesh Joshi <djo...@apache.org> wrote: > On Mon, Dec 9, 2024 at 12:26 PM Jon Haddad <j...@rustyrazorblade.com> > wrote: > >> I hope I've made my point. The bar for merging in new functionality >> should be higher. Features should work with 1TB of data on 3 nodes, that's >> a low bar. I've spent at least a thousand hours over the last 5 years >> developing the tooling to do these tests, there's no reason to not do them, >> and when we know things are broken, we shouldn't ship them. >> > > I am a big fan of early integration. I agree that the bar for merging > should be high but at the same time we should lean more heavily on feature > flagging which is also a very common software industry practice. This would > allow an operator to enable features that are deemed risky for production > use. It creates a faster feedback loop and will reveal issues earlier in > the development cycle. It might actually avoid big patches but that is a > topic for a different thread. > > Dinesh >
