Based on David and Blake’s responses, it sounds like we don’t need to block on anything.
I realize you may be making a broader point, but in this instance it sounds like there’s nothing here preventing an accord based MV implementation. Now that i understand more about how it would be done, it also sounds a lot simpler. On Thu, May 8, 2025 at 8:50 AM Josh McKenzie <jmcken...@apache.org> wrote: > IMHO, focus should be on accord-based MVs. Even if that means it's > blocked on first adding support for multiple conditions. > > Strongly disagree here. We should develop features to be as loosely > coupled w/one another as possible w/an eye towards future compatibility and > leverage but not block development of one functionality on something else > unless absolutely required for the feature to work (I'm defining "work" > here as "hits user requirements with affordances consistent w/the rest of > our ecosystem"). > > With the logic of deferring to another feature, it would have been quite > reasonable for someone to make this same statement back in fall of '23 when > we were discussing delaying 5.0 for Accord's merge. But things come up, the > space we're in is complex, and cutting edge distributed things are Hard. > > > On Thu, May 8, 2025, at 11:13 AM, Mick Semb Wever wrote: > > > > > Curious what others think though. I'm +1 on the spirit of getting MVs to > a stable point, but not convinced this is the best approach. > > > > > IMHO, focus should be on accord-based MVs. Even if that means it's > blocked on first adding support for multiple conditions. > > >
