On Mon, 2012-09-24 at 12:25 -0500, Seth Jennings wrote: > In summary, I really don't understand the objection to > promoting zcache and integrating zcache2 improvements and > features incrementally. It seems very natural and > straightforward to me. Rewrites can even happen in > mainline, as James pointed out. Adoption in mainline just > provides a more stable environment for more people to use > and contribute to zcache. This is slightly disingenuous. Acceptance into mainline commits us to the interface. Promotion from staging with simultaneous deprecation seems like a reasonable (if inelegant) compromise, but the problem is it's not necessarily a workable solution: as long as we have users of the interface in mainline, we can't really deprecate stuff however many feature deprecation files we fill in (I've had a deprecated SCSI ioctl set that's been deprecated for ten years and counting). What worries me looking at this fight is that since there's a use case for the old interface it will never really get removed. Conversely, rewrites do tend to vastly increase the acceptance cycle mainly because of reviewer fatigue (and reviews are our most precious commodity in the kernel). I'm saying rewrites should be possible in staging because it was always possible on plain patch submissions; I'm not saying they're desirable. Every time I've seen a rewrite done, it has added ~6mo-1yr to the acceptance cycle. I sense that the fatigue factor with transcendent memory is particularly high, so we're probably looking at the outside edge of the estimate, so the author needs seriously to consider if the rewrite is worth this. Oh, and while this spat goes on, the stalemate is basically assured and external goodwill eroding. So, for god's sake find a mutually acceptable compromise, because we're not going to find one for you. James _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
