On Mon, 17 Jan 2022, Daniel Vetter <daniel@xxxxxxxx> wrote: > Hi Helge > > On Fri, Jan 14, 2022 at 7:18 PM Helge Deller <deller@xxxxxx> 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@xxxxxx> >> >> 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@xxxxxxxxxxxxxxxxxxxxx >> +M: Helge Deller <deller@xxxxxx> >> L: linux-fbdev@xxxxxxxxxxxxxxx >> -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@xxxxxx [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
