From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Cc: "devel@driverdev.osuosl.org" <devel@driverdev.osuosl.org>,
Adrian Chadd <adrian@freebsd.org>, Jouni Malinen <j@w1.fi>,
Kalle Valo <kvalo@adurom.com>,
linux-wireless <linux-wireless@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Kathy Giori <Kathy.Giori@qca.qualcomm.com>,
Yanbo Li <dreamfly281@gmail.com>,
Mathieu Olivari <mathieu@qca.qualcomm.com>,
k.eugene.e@gmail.com
Subject: Re: Possibility for an external staging tree - bring up quality code
Date: Thu, 28 Mar 2013 15:53:00 -0700 [thread overview]
Message-ID: <20130328225300.GA20285@kroah.com> (raw)
In-Reply-To: <CAB=NE6WLuz7-QD3v4BwZkLLNUed=X7jgvZtZX8cDEh3HiD51oQ@mail.gmail.com>
On Thu, Mar 28, 2013 at 01:13:23PM -0700, Luis R. Rodriguez wrote:
<huge snip>
> This has me thinking if it makes sense to have an external driver tree
> for staging drivers but lead by engineers who already know the rules
> of upstream, they just want to get things done faster.
That's called a "fork" or "tree" or whatever you want to call it, and
all of us have them, and end up merging stuff to mainline through them
eventually.
There is no need to "codify" something that we all have been doing for
years. If someone thinks they can "work faster" in their own tree,
great for them, have them do it. I don't see what I need to agree or
disagree with here to keep anyone from doing such a thing.
Or am I just totally missing something here?
greg k-h
next prev parent reply other threads:[~2013-03-28 22:53 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-28 20:13 Possibility for an external staging tree - bring up quality code Luis R. Rodriguez
2013-03-28 22:53 ` Greg Kroah-Hartman [this message]
2013-03-29 0:46 ` Luis R. Rodriguez
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=20130328225300.GA20285@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=Kathy.Giori@qca.qualcomm.com \
--cc=adrian@freebsd.org \
--cc=devel@driverdev.osuosl.org \
--cc=dreamfly281@gmail.com \
--cc=j@w1.fi \
--cc=k.eugene.e@gmail.com \
--cc=kvalo@adurom.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=mathieu@qca.qualcomm.com \
--cc=mcgrof@do-not-panic.com \
/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;
as well as URLs for NNTP newsgroup(s).