On Sat, 2012-09-22 at 02:07 +0100, Mel Gorman wrote: > > The two proposals: > > A) Recreate all the work done for zcache2 as a proper sequence of > > independent patches and apply them to zcache1. (Seth/Konrad) > > B) Add zsmalloc back in to zcache2 as an alternative allocator > > for frontswap pages. (Dan) > > Throwing it out there but .... > > C) Merge both, but freeze zcache1 except for critical fixes. Only > allow > future work on zcache2. Document limitations of zcache1 and > workarounds until zcache2 is fully production ready. > Actually, there is a fourth option, which is the one we'd have usually used when staging wasn't around: Throw the old code out as a successful prototype which showed the author how to do it better (i.e. flush it from staging) and start again from the new code which has all the benefits learned from the old code. Staging isn't supposed to be some magical set of history that we have to adhere to no matter what (unlike the rest of the tree). It's supposed to be an accelerator to get stuff into the kernel and not become a hindrance to it. There also seem to be a couple of process issues here that could do with sorting: Firstly that rewrites on better reflection, while not common, are also not unusual so we need a mechanism for coping with them. This is actually a serious process problem: everyone becomes so attached to the code they helped clean up that they're hugely unwilling to countenance a rewrite which would in their (probably correct) opinion have the cleanups start from ground zero again. Secondly, we've got a set of use cases and add ons which grew up around code in staging that act as a bit of a barrier to ABI/API evolution, even as they help to demonstrate the problems. I think the first process issue really crystallises the problem we're having in staging: we need to get the design approximately right before we start on the code cleanups. What I think this means is that we start on the list where the people who understand the design issues reside then, when they're happy with the design, we can begin cleaning it up afterwards if necessary. I don't think this is hard and fast: there is, of course, code so bad that even the experts can't penetrate it to see the design without having their eyes bleed but we should at least always try to begin with design. James -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>