Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Jani Nikula <jani.nikula@linux.intel.com>]

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.


BR,
Jani.


[1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de
[2] https://lore.kernel.org/r/YeG8ydoJNWWkGrTb@ls3530
[3] https://lore.kernel.org/r/YeRyfaesC2kxkgZC@ls3530
[4] https://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git/commit/?h=for-next&id=a8005a65d06cfb89585574d956d80b6e23012caa
[5] https://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git/commit/?h=for-next&id=9a89eeda722231fd1079dbfab4a9769b4beb868d


-- 
Jani Nikula, Intel Open Source Graphics Center