Date:   Mon, 17 Jan 2022 11:57:38 +0100
From:   Helge Deller <deller@....de>
To:     Jani Nikula <jani.nikula@...ux.intel.com>,
        Daniel Vetter <daniel@...ll.ch>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        "airlied@...il.com" <airlied@...il.com>
Cc:     linux-fbdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        dri-devel@...ts.freedesktop.org,
        Javier Martinez Canillas <javierm@...hat.com>
Subject: Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

Hello Jani,

On 1/17/22 11:49, Jani Nikula wrote:
> On Mon, 17 Jan 2022, Daniel Vetter <daniel@...ll.ch> wrote:
>> Hi Helge
>>
>> On Fri, Jan 14, 2022 at 7:18 PM Helge Deller <deller@....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@....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@...ts.freedesktop.org
>>> +M:     Helge Deller <deller@....de>
>>>  L:     linux-fbdev@...r.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

Powered by blists - more mailing lists