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
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.
Hi Paul,
On Tue, 9 Nov 2010 18:32:04 +0900 Paul Mundt <[email protected]> wrote:
>
> The tree can be found at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/lethal/fbdev-2.6.git
>
> 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.
Added from next-20101110. I also have a viafb and omap_dss2 trees in
linux-next that are owned by Florian Tobias Schandinat and Tomi Valkeinen
respectively (cc'd). There is no reason that these trees cannot remain in
linux-next even if you merge them as well.
Currently you are the only listed contact for the fbdev tree.
Thanks for adding your subsystem tree as a participant of linux-next. As
you may know, this is not a judgment of your code. The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window.
You will need to ensure that the patches/commits in your tree/series have
been:
* submitted under GPL v2 (or later) and include the Contributor's
Signed-off-by,
* posted to the relevant mailing list,
* reviewed by you (or another maintainer of your subsystem tree),
* successfully unit tested, and
* destined for the current or next Linux merge window.
Basically, this should be just what you would send to Linus (or ask him
to fetch). It is allowed to be rebased if you deem it necessary.
--
Cheers,
Stephen Rothwell
[email protected]
Legal Stuff:
By participating in linux-next, your subsystem tree contributions are
public and will be included in the linux-next trees. You may be sent
e-mail messages indicating errors or other issues when the
patches/commits from your subsystem tree are merged and tested in
linux-next. These messages may also be cross-posted to the linux-next
mailing list, the linux-kernel mailing list, etc. The linux-next tree
project and IBM (my employer) make no warranties regarding the linux-next
project, the testing procedures, the results, the e-mails, etc. If you
don't agree to these ground rules, let me know and I'll remove your tree
from participation in linux-next.
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: [email protected]
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Tue, Nov 09, 2010 at 12:56:48PM -0300, Davidlohr Bueso wrote:
> On Tue, 2010-11-09 at 18:32 +0900, Paul Mundt wrote:
> > 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: [email protected]
> 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*
>
Yes, I'll queue an update for that later. I was going to wait until the
patchwork stuff came up and then update it all in one shot.
On Wed, Nov 10, 2010 at 01:22:49AM +0900, Paul Mundt wrote:
> On Tue, Nov 09, 2010 at 12:56:48PM -0300, Davidlohr Bueso wrote:
> > On Tue, 2010-11-09 at 18:32 +0900, Paul Mundt wrote:
> > > 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: [email protected]
> > 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*
> >
> Yes, I'll queue an update for that later. I was going to wait until the
> patchwork stuff came up and then update it all in one shot.
Ok, the patchwork queue is up now also:
https://patchwork.kernel.org/project/linux-fbdev/list/