Hello Jani, On 1/17/22 11:49, Jani Nikula wrote: > 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. 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
