All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: Andreas Dilger <adilger@dilger.ca>,
	Oleg Drokin <oleg.drokin@intel.com>,
	Andreas Dilger <andreas.dilger@intel.com>,
	James Simmons <jsimmons@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linuxfoundation.org>,
	lustre-devel <lustre-devel@lists.lustre.org>,
	fsdevel <linux-fsdevel@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	devel@driverdev.osuosl.org, selinux@tycho.nsa.gov
Subject: Re: [PATCH] staging: lustre: delete the filesystem from the tree.
Date: Mon, 4 Jun 2018 09:14:43 +0200	[thread overview]
Message-ID: <20180604071443.GA32335@kroah.com> (raw)
In-Reply-To: <20180604070922.GA13156@infradead.org>

On Mon, Jun 04, 2018 at 12:09:22AM -0700, Christoph Hellwig wrote:
> On Fri, Jun 01, 2018 at 09:08:39PM +0200, Greg Kroah-Hartman wrote:
> > Please, compare yourself to orangefs.  That is the perfect example of
> > how to do everything right.  They got their code into staging, cleaned
> > it up, talked to us about what was needed to do to get the remaining
> > bits in proper shape, they assigned dedicated developers to do that
> > work, talked with all of us at different conferences around the world to
> > check up and constantly ensure that they were doing the right thing, and
> > most importantly, they asked for feedback and acted on it.  In the end,
> > their codebase is much smaller, works better, is in the "real" part of
> > the kernel, and available to every Linux user out there.
> 
> FYI, orangefs never went through the statging tree.  Which might be
> one reason why it got merged so quickly - allowing rapid iteration
> without respect to merged windows, and doing all the trivial cleanups
> either before or after (but not at the same time as) the feature
> work really does help productivity.

Ah, my mistake, for some reason I thought it did, I guess I had offered
to take it that way if the developers wanted it.

And yes, doing all of the needed cleanups and other changes outside of
the kernel tree should be much much faster, which is why I bet it would
only take 6 months max to get lustre merged "properly" if they really
wanted to do it, by working out-of-tree.

Heck, they already have an out-of-tree repo today, so it's not like
removing the in-kernel version is going to change their normal
development workflow :(

greg k-h

WARNING: multiple messages have this Message-ID (diff)
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: Andreas Dilger <adilger@dilger.ca>,
	Oleg Drokin <oleg.drokin@intel.com>,
	Andreas Dilger <andreas.dilger@intel.com>,
	James Simmons <jsimmons@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linuxfoundation.org>,
	lustre-devel <lustre-devel@lists.lustre.org>,
	fsdevel <linux-fsdevel@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	devel@driverdev.osuosl.org, selinux@tycho.nsa.gov
Subject: [lustre-devel] [PATCH] staging: lustre: delete the filesystem from the tree.
Date: Mon, 4 Jun 2018 09:14:43 +0200	[thread overview]
Message-ID: <20180604071443.GA32335@kroah.com> (raw)
In-Reply-To: <20180604070922.GA13156@infradead.org>

On Mon, Jun 04, 2018 at 12:09:22AM -0700, Christoph Hellwig wrote:
> On Fri, Jun 01, 2018 at 09:08:39PM +0200, Greg Kroah-Hartman wrote:
> > Please, compare yourself to orangefs.  That is the perfect example of
> > how to do everything right.  They got their code into staging, cleaned
> > it up, talked to us about what was needed to do to get the remaining
> > bits in proper shape, they assigned dedicated developers to do that
> > work, talked with all of us at different conferences around the world to
> > check up and constantly ensure that they were doing the right thing, and
> > most importantly, they asked for feedback and acted on it.  In the end,
> > their codebase is much smaller, works better, is in the "real" part of
> > the kernel, and available to every Linux user out there.
> 
> FYI, orangefs never went through the statging tree.  Which might be
> one reason why it got merged so quickly - allowing rapid iteration
> without respect to merged windows, and doing all the trivial cleanups
> either before or after (but not at the same time as) the feature
> work really does help productivity.

Ah, my mistake, for some reason I thought it did, I guess I had offered
to take it that way if the developers wanted it.

And yes, doing all of the needed cleanups and other changes outside of
the kernel tree should be much much faster, which is why I bet it would
only take 6 months max to get lustre merged "properly" if they really
wanted to do it, by working out-of-tree.

Heck, they already have an out-of-tree repo today, so it's not like
removing the in-kernel version is going to change their normal
development workflow :(

greg k-h

  reply	other threads:[~2018-06-04  7:15 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-01  9:11 [PATCH] staging: lustre: delete the filesystem from the tree Greg Kroah-Hartman
2018-06-01  9:11 ` [lustre-devel] " Greg Kroah-Hartman
2018-06-01 11:41 ` Christoph Hellwig
2018-06-01 11:41   ` [lustre-devel] " Christoph Hellwig
2018-06-01 18:20   ` Andreas Dilger
2018-06-01 18:20     ` [lustre-devel] " Andreas Dilger
2018-06-01 18:25     ` Doug Oucharek
2018-06-01 18:25       ` Doug Oucharek
2018-06-01 23:19       ` NeilBrown
2018-06-01 23:19         ` NeilBrown
2018-06-03 20:34         ` Dilger, Andreas
2018-06-03 20:34           ` Dilger, Andreas
2018-06-04  3:54           ` NeilBrown
2018-06-04  3:54             ` NeilBrown
2018-06-04  3:59             ` Alexey Lyashkov
2018-06-04  3:59               ` Alexey Lyashkov
2018-06-04  4:15               ` Andreas Dilger
2018-06-04  4:15                 ` Andreas Dilger
2018-06-04  4:17                 ` Alexey Lyashkov
2018-06-04  4:17                   ` Alexey Lyashkov
2018-06-01 18:30 ` Andreas Dilger
2018-06-01 18:30   ` [lustre-devel] " Andreas Dilger
2018-06-01 18:41   ` Oleg Drokin
2018-06-01 18:41     ` [lustre-devel] " Oleg Drokin
2018-06-01 19:08   ` Greg Kroah-Hartman
2018-06-01 19:08     ` [lustre-devel] " Greg Kroah-Hartman
2018-06-04  7:09     ` Christoph Hellwig
2018-06-04  7:09       ` [lustre-devel] " Christoph Hellwig
2018-06-04  7:14       ` Greg Kroah-Hartman [this message]
2018-06-04  7:14         ` Greg Kroah-Hartman
2018-06-02  0:28 ` NeilBrown
2018-06-02  0:28   ` NeilBrown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180604071443.GA32335@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=adilger@dilger.ca \
    --cc=akpm@linux-foundation.org \
    --cc=andreas.dilger@intel.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=hch@infradead.org \
    --cc=jsimmons@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lustre-devel@lists.lustre.org \
    --cc=oleg.drokin@intel.com \
    --cc=selinux@tycho.nsa.gov \
    --cc=torvalds@linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.