From: Davidlohr Bueso <dave@gnu.org>
To: Paul Mundt <lethal@linux-sh.org>
Cc: linux-fbdev@vger.kernel.org,
Geert Uytterhoeven <geert@linux-m68k.org>,
James Simmons <jsimmons@infradead.org>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Andrew Morton <akpm@linux-foundation.org>,
Dave Airlie <airlied@linux.ie>,
linux-kernel@vger.kernel.org
Subject: Re: [ANNOUNCE] fbdev git tree.
Date: Tue, 09 Nov 2010 15:56:48 +0000 [thread overview]
Message-ID: <1289318208.2260.9.camel@cowboy> (raw)
In-Reply-To: <20101109093204.GB21086@linux-sh.org>
On Tue, 2010-11-09 at 18:32 +0900, Paul Mundt wrote:
> As I find myself spending more time reviewing and merging fbdev patches
> lately, and in an effort to offload some of the pressure on -mm, I've
> opted to start a git tree to start collecting and merging fbdev changes.
>
> I plan to get a patchwork queue established for the list as well so that
> things don't fall through the cracks (the link will be posted once it's
> been established). People will be able to see the status of their patches
> this way, rather than wondering whether things are being picked up,
> overlooked, or forced through an alternate merge strategy (We have had
> reasonable success with this with the SH tree, so here's hoping that the
> same approach will work well here, too).
>
> I've already made a note about this to akpm off-list, so fbdev patches
> that pop up outside of the regular channels that I may be unaware of
> should still have a reasonable chance of being intercepted and rerouted
> (although the mmotm is rather devoid of drivers/video churn at the
> moment).
>
> I'll be combing through the list archives to see if there is anything
> glaringly outstanding (the HDMI/EDID work comes to mind) and working on
> getting the oustanding issues there resolved. If anyone has any
> outstanding patches that have fallen through the cracks, now would be a
> good time to provide pointers!
>
> Given the point that we're at with .38 bits now and a cursory look at
> -next shows that there's already quite a bit of drivers/video churn
> coming in from git trees. It will likely take a few cycles to get people
> used to the idea of there being an active fbdev tree to merge through,
> but with any luck it will be a fairly natural transition. I'll be
> contacting and working with git tree owners separately so there aren't
> any surprises.
>
> The tree can be found at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/lethal/fbdev-2.6.git
>
Could this be added to the MAINTAINERS file?
FRAMEBUFFER LAYER
L: linux-fbdev@vger.kernel.org
W: http://linux-fbdev.sourceforge.net/
+T:
git://git.kernel.org/pub/scm/linux/kernel/git/lethal/fbdev-2.6.git
S: Orphan
F: Documentation/fb/
F: drivers/video/fb*
> Stephen, if you could add this with the master branch to -next, it would
> be appreciated. For the moment I expect most of the patches to follow a
> fairly linear line of development, but there may be cause for topic
> branches as new (or contested) patch sets arise.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
WARNING: multiple messages have this Message-ID (diff)
From: Davidlohr Bueso <dave@gnu.org>
To: Paul Mundt <lethal@linux-sh.org>
Cc: linux-fbdev@vger.kernel.org,
Geert Uytterhoeven <geert@linux-m68k.org>,
James Simmons <jsimmons@infradead.org>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Andrew Morton <akpm@linux-foundation.org>,
Dave Airlie <airlied@linux.ie>,
linux-kernel@vger.kernel.org
Subject: Re: [ANNOUNCE] fbdev git tree.
Date: Tue, 09 Nov 2010 12:56:48 -0300 [thread overview]
Message-ID: <1289318208.2260.9.camel@cowboy> (raw)
In-Reply-To: <20101109093204.GB21086@linux-sh.org>
On Tue, 2010-11-09 at 18:32 +0900, Paul Mundt wrote:
> As I find myself spending more time reviewing and merging fbdev patches
> lately, and in an effort to offload some of the pressure on -mm, I've
> opted to start a git tree to start collecting and merging fbdev changes.
>
> I plan to get a patchwork queue established for the list as well so that
> things don't fall through the cracks (the link will be posted once it's
> been established). People will be able to see the status of their patches
> this way, rather than wondering whether things are being picked up,
> overlooked, or forced through an alternate merge strategy (We have had
> reasonable success with this with the SH tree, so here's hoping that the
> same approach will work well here, too).
>
> I've already made a note about this to akpm off-list, so fbdev patches
> that pop up outside of the regular channels that I may be unaware of
> should still have a reasonable chance of being intercepted and rerouted
> (although the mmotm is rather devoid of drivers/video churn at the
> moment).
>
> I'll be combing through the list archives to see if there is anything
> glaringly outstanding (the HDMI/EDID work comes to mind) and working on
> getting the oustanding issues there resolved. If anyone has any
> outstanding patches that have fallen through the cracks, now would be a
> good time to provide pointers!
>
> Given the point that we're at with .38 bits now and a cursory look at
> -next shows that there's already quite a bit of drivers/video churn
> coming in from git trees. It will likely take a few cycles to get people
> used to the idea of there being an active fbdev tree to merge through,
> but with any luck it will be a fairly natural transition. I'll be
> contacting and working with git tree owners separately so there aren't
> any surprises.
>
> The tree can be found at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/lethal/fbdev-2.6.git
>
Could this be added to the MAINTAINERS file?
FRAMEBUFFER LAYER
L: linux-fbdev@vger.kernel.org
W: http://linux-fbdev.sourceforge.net/
+T:
git://git.kernel.org/pub/scm/linux/kernel/git/lethal/fbdev-2.6.git
S: Orphan
F: Documentation/fb/
F: drivers/video/fb*
> Stephen, if you could add this with the master branch to -next, it would
> be appreciated. For the moment I expect most of the patches to follow a
> fairly linear line of development, but there may be cause for topic
> branches as new (or contested) patch sets arise.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
next prev parent reply other threads:[~2010-11-09 15:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-09 9:32 [ANNOUNCE] fbdev git tree Paul Mundt
2010-11-09 9:32 ` Paul Mundt
2010-11-09 15:19 ` Stephen Rothwell
2010-11-09 15:19 ` Stephen Rothwell
2010-11-09 15:56 ` Davidlohr Bueso [this message]
2010-11-09 15:56 ` Davidlohr Bueso
2010-11-09 16:22 ` Paul Mundt
2010-11-09 16:22 ` Paul Mundt
2010-11-17 4:00 ` Paul Mundt
2010-11-17 4:00 ` Paul Mundt
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=1289318208.2260.9.camel@cowboy \
--to=dave@gnu.org \
--cc=airlied@linux.ie \
--cc=akpm@linux-foundation.org \
--cc=geert@linux-m68k.org \
--cc=jsimmons@infradead.org \
--cc=lethal@linux-sh.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sfr@canb.auug.org.au \
/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.