public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Christoph Hellwig <hch@infradead.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	devel@linuxdriverproject.org, linux-kernel@vger.kernel.org
Subject: Re: [GIT PULL] Staging/IIO driver patches for 5.4-rc1
Date: Wed, 18 Sep 2019 13:47:15 -0700	[thread overview]
Message-ID: <20190918204715.GA15538@infradead.org> (raw)
In-Reply-To: <20190918185010.GA1933470@kroah.com>

On Wed, Sep 18, 2019 at 08:50:10PM +0200, Greg KH wrote:
> > exfat is just a random old code drop from Samsung hastily picked up,
> > and also duplicating the fat16/32 functionality, and without
> > consultation of the developes of that who are trying to work through
> > their process of contributing the uptodate and official version of it.
> 
> Those developers are still yet to be found, we only got a "drop" of the
> samsung code _after_ this code was merged, from non-samsung people.  No
> samsung developers have said they would actually help with any of this
> work, and when asked what differed from the in-tree stuff, I got a list,
> but no specifics.  I'll be working through that list over the next month
> to resolve those issues.

Park offered to help with a new version, and the Samsung guys are going
through their internal review process to work upstream it.  Remember
it is their codebase in each of the variants here.  While it is fine
if we take some code that has been abandoned by the original developers
and still merge it with helping hands I think it is very rude to not
at least wait for them to get their act of working with their corporate
overlords together first.  It isn't like we've been waiting forever
for an exfat driver - the patent grant has been extremely recent, and
this whole thing just seems like a publicity stunt to be honest.  Give
them a couple weeks to sort their stuff out and then we can decide
how to proceed.  I for one would defintively prefer to have code
maintained by the original maintainers if possible.  And not have
them hindered by the staging process to work on their own code.

> To get back to the meta-problem here, we need a common "vfs/filesystem"
> tree somewhere with reviewers.  I'm glad to set up the tree and handle
> patches, but I am not a vfs expert by any means (I only understand the
> virtual half, not the backing half), so I can't be the only one to do
> reviews.  Do you know of anyone that we can drag in as reviewers to help
> make it easier for new filesystems to get reviews as well as existing
> ones to have their patches collected and forwarded on to Linus at the
> proper times?

Following how staging works and its arcane rules I don't want it to be
anywhere near fs code.  And seriously, it is not like we need one
magic tree to deal with all file systems.  The whole point of git is
that people can setup a tree to collaborate wherever they want if you
just find people to work on it.  And we've had tons of successful
drivers and filesystems that worked that way.  And at least the ones
I've followed seem a lot more productive than the staging show that
is baѕed around coding style cleanup micropatches.

  reply	other threads:[~2019-09-18 20:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-18 11:47 [GIT PULL] Staging/IIO driver patches for 5.4-rc1 Greg KH
2019-09-18 18:20 ` pr-tracker-bot
2019-09-18 18:24 ` Christoph Hellwig
2019-09-18 18:50   ` Greg KH
2019-09-18 20:47     ` Christoph Hellwig [this message]
2019-09-18 21:11   ` Gao Xiang
2019-09-18 22:44     ` Gao Xiang

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=20190918204715.GA15538@infradead.org \
    --to=hch@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=devel@linuxdriverproject.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sfr@canb.auug.org.au \
    --cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox