Re: [PATCH 1/4] Support generic I/O requests

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2 Jun 2010 15:20:13 +0900
Minchan Kim <minchan.kim@xxxxxxxxx> wrote:

> P.S)
> Why don't you send this series to -mm?
> I don't know any patches have to go linux-next and any patches have to
> go --mmotm.

The code lives in drivers/staging/ at present.  That's Greg's tree.

> 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/.

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.


_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel


[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux