lkml.org 
[lkml]   [2022]   [Jan]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
From
Hello Jani,

On 1/17/22 11:49, Jani Nikula wrote:
> On Mon, 17 Jan 2022, Daniel Vetter <daniel@ffwll.ch> wrote:
>> Hi Helge
>>
>> On Fri, Jan 14, 2022 at 7:18 PM Helge Deller <deller@gmx.de> wrote:
>>>
>>> The fbdev layer is orphaned, but seems to need some care.
>>> So I'd like to step up as new maintainer.
>>>
>>> Signed-off-by: Helge Deller <deller@gmx.de>
>>>
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index 5d0cd537803a..ce47dbc467cc 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -7583,11 +7583,12 @@ W: http://floatingpoint.sourceforge.net/emulator/index.html
>>> F: arch/x86/math-emu/
>>>
>>> FRAMEBUFFER LAYER
>>> -L: dri-devel@lists.freedesktop.org
>>> +M: Helge Deller <deller@gmx.de>
>>> L: linux-fbdev@vger.kernel.org
>>> -S: Orphan
>>
>> Maybe don't rush maintainer changes in over the w/e without even bothering
>> to get any input from the people who've been maintaining it before.
>>
>> Because the status isn't entirely correct, fbdev core code and fbcon and
>> all that has been maintained, but in bugfixes only mode. And there's very
>> solid&important reasons to keep merging these patches through a drm tree,
>> because that's where all the driver development happens, and hence also
>> all the testing (e.g. the drm test suite has some fbdev tests - the only
>> automated ones that exist to my knowledge - and we run them in CI). So
>> moving that into an obscure new tree which isn't even in linux-next yet is
>> no good at all.
>>
>> Now fbdev driver bugfixes is indeed practically orphaned and I very much
>> welcome anyone stepping up for that, but the simplest approach there would
>> be to just get drm-misc commit rights and push the oddball bugfix in there
>> directly. But also if you want to do your own pull requests to Linus for
>> that I don't care and there's really no interference I think, so
>> whatever floats.
>>
>> But any code that is relevant for drm drivers really needs to go in through
>> drm trees, nothing else makes much sense.
>>
>> I guess you're first action as newly minted fbdev maintainer is going to be to
>> clean up the confusion you just created.
>
> As much as I like folks stepping up as maintainers, I've got to say this
> is not a style I appreciate at all.
>
> Thursday: Object a recent fbdev change [1].
>
> Friday: Step up as fbdev maintainer, change git tree (this thread) [2].
>
> Sunday: Send the maintainer change to Linus [3].
>
> Later Sunday: Start reverting the changes objected to on Thursday, with
> no discussion, no acks, no reviews, in the new git tree [4].
>
> Monday: Continue reverting the changes [5].
>
> I'm heavily in favor of maintainers who are open, transparent,
> collaborative, who seek consensus through discussion, and only put their
> foot down when required.
>
> I really don't like the optics here. I'd expect some pretty good
> explanations.

Jani, please don't worry!
I've started to sort things out, to work through the existing backlog of
patches (which is a LOT!) and nothing has been pushed yet.
I've seen the other mails and we will discuss.

So, please just ignore the current state of the linux-fbdev tree for now.

Helge

\
 
 \ /
  Last update: 2022-01-17 11:59    [W:0.182 / U:0.144 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site