On Thu, Jun 16, 2011 at 11:38:48AM -0300, Marcelo Tosatti wrote: > > People seem to agree on this, and the reason that I've heard why we > > should merge the existing code instead is downstream time pressure. That > > may be a valid reason for downstreams to add such code, but is taking > > such code really the best option for upstream (and therefore long-term > > for downstreams)? > > > > If we take these patches as they are, I doubt that we'll ever get a > > rewrite to implement the code as it should have been done in the first > > place. > > That (a newer, unified mechanism) is just a matter of allocating > resources to the implementation. > > At least in block copy's case the interface can be reused, so it can be > seen as an incremental approach (read: advocating in favour of merging > live block copy patchset). > > > So I'm tempted to reject the current versions of both the image > > streaming and live block copy series and leave it to downstreams to use > > these as temporary solutions if the time pressure is too high. I know > > that maintaining things downstream is painful, but that's the whole > > point: I want to see the real implementation one day, and I'm afraid > > this might be the only way to get it.
Again: there is no need to reject current live block copy implementation, as image streaming implemented for generic image formats is a strong motivator behind the unified implementation.
