Re: [GIT PULL] ext4 updates for 3.11

[Greg KH]

On Thu, Jul 04, 2013 at 09:54:44AM +1000, Dave Chinner wrote:
> On Wed, Jul 03, 2013 at 06:40:40PM +0000, Dilger, Andreas wrote:
> > On 2013/03/07 12:12 PM, "Greg KH" <greg@xxxxxxxxx> wrote:
> > >On Wed, Jul 03, 2013 at 01:29:41PM +1000, Dave Chinner wrote:
> > >> On Tue, Jul 02, 2013 at 06:01:11PM -0700, Greg KH wrote:
> > >> > For this filesystem, it seems that they don't have any
> > >> > resources to do this work and are relying on the community to
> > >> > help out.  Which is odd, but big companies are strange some
> > >> > times...
> > >> 
> > >> Didn't we learn this lesson already with POHMELFS? i.e. that
> > >> dumping filesystem code in staging on the assumption "the
> > >> community" will fix it up when nobody in "the community" uses
> > >> or can even test that filesystem is a broken development
> > >> model....
> > >
> > >They (Intel) has said that they will continue to clean up this
> > >code in the tree, until it is in good enough shape to be merged
> > >into fs/ properly.  If they ever stop helping out, I will end up
> > >dropping it from the tree, just like I did for pohmelfs, so don't
> > >worry about it lingering around abandoned.
> > 
> > Right, we are going to continue working on cleaning the code at a
> > steady pace until it is ready to move to fs/.  I don't expect Al
> > or Dave or Christoph to spend their time (or make their eyes
> > bleed) with the current state of the code.  It has already
> > undergone some significant cleanup, but needs a bunch more still.
> 
> The issue I'm more concerned about is more to do with what happens
> when we do something that affects all filesystems, such as API
> changes. Then we are forced to look at it and to try to work out
> what the hell is going on. This was the real problem with pomelhfs
> being in staging - it had an unreasonably high maintenance overhead
> compared to other filesystems.
> 
> This was mainly because pohelmfs was effectively dumped in staging
> and then left unmaintained - if there's consistent effort put into
> the Lustre code to clean it up, maintain it and help with API
> transitions, then I have nothing to object to and I'll just crawl
> back into my box. ;)

Again, as with all code in the drivers/staging/ area, if you change any
kernel apis, you are not responsible for fixing up the staging drivers,
that's my job.  A heads-up is always nice, but again, not required.  You
should be able to just safely ignore them if you don't want to ever look
at them.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/