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?
Pekka
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
