Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp2969699pxb; Mon, 17 Jan 2022 09:11:31 -0800 (PST) X-Google-Smtp-Source: ABdhPJx3n8ZRN0EMYDO/T0KxKvOWzEEpY79XvCRm7l73tnvbgS8KgpdZmz55dQHzQSpgD82dcOUy X-Received: by 2002:a17:90b:4b41:: with SMTP id mi1mr19368258pjb.1.1642439491017; Mon, 17 Jan 2022 09:11:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642439491; cv=none; d=google.com; s=arc-20160816; b=Abq+Zptu9NUpioOW3Apf+LND7j94yLow0DuNSwIgDJn1eXM+vaIU8lpye4n6mtTVnn 6JEzJDR2sPjSgW0ULd/GsHELnQ46zA6iS4mZlikfzrfLcw97f/VfmcmYiOyhTJxRWWZK ze1p8w/CsFTwtIDjTUuTy37mvfJJQUZe+svFrMaUz9KMHAKD31/bqzLwjKMhIyQR93Wd xB0hnt7bsmTr2DGDXXvfn4bSH95OXvAP9OSlyJgI9M30mT2nOh/CnR2XMKSGpAwUBuc5 M/+g+WJDo6X37MiqzG6KAq8aXwReaJ44OQIb276NHkgNsECtYSySQKffHEhDzY/kE+OR 6Gbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :organization:in-reply-to:subject:cc:to:from:dkim-signature; bh=8zDgo47AT/5XxUM2p+5n4vz4WGgVCY5KuTzLnsokD0E=; b=e3ATid0cIq+s4uyCQC0g15o6vv4+pcPmpnKg4P1cK5SftvVr2pd4BZZi1ny2UQrQA8 TtxhbpdmVd6h8/zoy9AnsbkVlv+YJKac7sdaZPP4GRS3WWSiAOBEm7UHsigalSG0v/QQ EhdAf8Dq4wMMUwHVxKgrp8hmEVjinrXHV8EhxDU7P+dR80JbPWzgSvUC9eZktje+c28j Wm48dkln27NXXMew68B98EJspq41+CFosGXPHtK9tElQ73WX5jCz8yqCBpmNElFWH5oO Pw9PUsbSEmf877FvdVnsjV7S3KYYj5NKDW/7Sf0ZzVPdky+NnKQL2KE/oisKg+PMrgLO xmXg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="du/2Bu+H"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c1si9732354plg.212.2022.01.17.09.11.18; Mon, 17 Jan 2022 09:11:31 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="du/2Bu+H"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238755AbiAQKt7 (ORCPT + 99 others); Mon, 17 Jan 2022 05:49:59 -0500 Received: from mga14.intel.com ([192.55.52.115]:29944 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231277AbiAQKt6 (ORCPT ); Mon, 17 Jan 2022 05:49:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1642416598; x=1673952598; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=+F3cr2LC9C2ZI7Rd8QEaWqzsRs3Pay43Ar9tUq2gZg8=; b=du/2Bu+HOsxISVEc2SZWEqB27NjdOuOGd27FuJvqPvpSyev4P4BDX/Oc xoFO6eA6tbv1V6x992+mxUBE+nv6OVIV6Y1WV/6Ow6zD/lLehW7cCQaso U1WTHBS4KWB5gJ0466NqvI/aX9KTjDj/OSMLp9AyQldZPDZbsSqsc2//L kscHoztU6jsx/yrWyVJbcgpUBkM56ghyO2rSyV69gxLDGxRBusUB1+8yi x9MzI5704KGd8LUrY17Ioagjn5yzLSTS+I4Cu1O8vfzGuvHj3F/U8PWaj IjwaYnAv499gSnvjWwJ5bJTxYIVeYyM9oHm6/1J9DxRuWOctqEK8JV9lk w==; X-IronPort-AV: E=McAfee;i="6200,9189,10229"; a="244797820" X-IronPort-AV: E=Sophos;i="5.88,295,1635231600"; d="scan'208";a="244797820" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jan 2022 02:49:58 -0800 X-IronPort-AV: E=Sophos;i="5.88,295,1635231600"; d="scan'208";a="476605640" Received: from nsilva2-mobl1.amr.corp.intel.com (HELO localhost) ([10.252.2.18]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jan 2022 02:49:54 -0800 From: Jani Nikula To: Daniel Vetter , Helge Deller , Linus Torvalds , "airlied@gmail.com" Cc: linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Javier Martinez Canillas Subject: Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: Date: Mon, 17 Jan 2022 12:49:45 +0200 Message-ID: <87o84a63hy.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 17 Jan 2022, Daniel Vetter wrote: > Hi Helge > > On Fri, Jan 14, 2022 at 7:18 PM Helge Deller 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 >> >> 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 >> 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