Hi, Pekka. On Sat, Jun 5, 2010 at 5:35 PM, Pekka Enberg <penberg@xxxxxxxxxxxxxx> wrote: > Hi Andrew, > > On Fri, Jun 4, 2010 at 10:19 PM, Andrew Morton > <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: >>> I thought zram is related to memory management a little bit. >>> >>> What's the criteria? >> >> Yes, and this is something which bothers me a bit about the -staging >> process. Code gets in there largely under the radar of the people who >> work in that area. It gets "matured" for a while and the developer >> thinks it's all ready to go into "mainline" and .... then what? >> Someone needs to yank the code out of -staging and tell the interested >> parties "hey, look at this". And at this stage, they might say "hell >> no", or request large changes and the developer who thought everything >> was all ready to go would be justifiably upset. >> >> Obviously, this hasn't happened (much) with zram (partly because I >> happened to notice it), but the potential is there. >> >> I'm not sure what a good solution is, really. Obviously it would be >> better if such code went straight into the subsystem maintainer's tree >> on day one and got worked on there. But if that process was working >> efficiently, we wouldn't have ever needed ./staging/. > > I thought the idea here is that when zram is "good enough", Nitin or > Greg would post squashed patches of it for review and if maintainers > are ready to take it, we'd merge the full history from -staging. > > Not sure what Nitin's or Greg's plans are but I think it might be > realistic to try to get zram properly merged for 2.6.36. > >> So I suppose we (ie: Greg ;)) should identify the destination >> maintainer at the outset and make sure that the maintainer(s) and the >> subsystem mailing list are kept in the loop on all developments, and >> that they're aware that this code is headed their way. Perhaps that's >> already happening and I missed it. > > Ramzswap and zram have been discussed on LKML. I guess Nitin should > have CC'd linux-mm as well for you to see it? There hasn't been huge > interest in reviewing the code which is why I suggested -staging in > the first place. It ought to be a place where we can do in-tree > development while we wait for the busy maintainers to have the chance > to look at the code, no? Fair enough. AFAIR, mm forks haven't been interest in reviewing the code except allocator at that time. but at least, Greg or someone should have Cced one maintainer or mailing list related to patches to notice them. "It's growing in here(ie, staging) and be ready to go to the mainline". :) -- Kind regards, Minchan Kim _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
