lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160323000835.GQ19428@n2100.arm.linux.org.uk>
Date:	Wed, 23 Mar 2016 00:08:35 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Inki Dae <inki.dae@...sung.com>
Cc:	Heiko Stübner <heiko@...ech.de>,
	David Airlie <airlied@...ux.ie>,
	Mark Yao <mark.yao@...k-chips.com>,
	Ajay Kumar <ajaykumar.rs@...sung.com>,
	Javier Martinez Canillas <javier@....samsung.com>,
	Doug Anderson <dianders@...omium.org>,
	Jingoo Han <jingoohan1@...il.com>,
	Yakir Yang <ykk@...k-chips.com>,
	Andrzej Hajda <a.hajda@...sung.com>,
	Joonyoung Shim <jy0922.shim@...sung.com>,
	Seung-Woo Kim <sw0312.kim@...sung.com>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	Thierry Reding <treding@...dia.com>,
	Krzysztof Kozlowski <k.kozlowski@...sung.com>,
	Rob Herring <robh+dt@...nel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	linux-samsung-soc <linux-samsung-soc@...r.kernel.org>,
	Pawel Moll <pawel.moll@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	"open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
	emil.l.velikov@...il.com,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Daniel Kurtz <djkurtz@...omium.org>,
	Kishon Vijay Abraham I <kishon@...com>,
	Kukjin Kim <kgene@...nel.org>,
	Sean Paul <seanpaul@...omium.org>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	Kumar Gala <galak@...eaurora.org>,
	Ajay kumar <ajaynumb@...il.com>,
	Rob Herring <robherring2@...il.com>,
	Andy Yan <andy.yan@...k-chips.com>,
	Gustavo Padovan <gustavo.padovan@...labora.co.uk>,
	Caesar Wang <caesar.upstream@...il.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: Who is going to merge it [Was: Re: [PATCH v14 0/17] Add Analogix
 Core Display Port Driver]

On Wed, Mar 23, 2016 at 08:54:15AM +0900, Inki Dae wrote:
> 

Please wrap your long lines.

> 
> 2016년 03월 23일 08:39에 Russell King - ARM Linux 이(가) 쓴 글:
> > On Wed, Mar 23, 2016 at 08:09:33AM +0900, Inki Dae wrote:
> >> In this case, someone else may send an email again like you "who is going to merge?"
> >> That would be why we need a maintainer.
> >>
> >> drm panel is already managed well by Thierry Reding without such confusion. 
> > 
> > You don't need a maintainer for every subdirectory just because it's
> > a subdirectory...
> > 
> > Sometimes, having too many maintainers adds beaurocracy which becomes
> 
> Yes, but... if there is no someone who is responsible for maintainership,
> then we would receive such emails like Heiko sent "who is going to merge" 
> I don't also want adding many maintainers unnecessary but drm bridge -
> although the framework is a thin and small - is used *over the ARM SoC*
> so that many confusions may happen for upstream.

Just because someone asks doesn't mean someone needs to be appointed.
Maybe the question that should be asked instead is whether the original
author is willing to maintain their driver.

> So although it's small framework or just subdirectory, we would need
> someone who can manage the framework to avoid further confusion if
> necessary.

So maybe it just doesn't need a maintainer, and maybe those the owner
of the bridge driver should be responsible for choosing the tree which
it's merged through along with updates.  That's how dw-hdmi has been
managed on the whole.

It also means that the bridge driver maintainer is able to test changes
to the bridge driver, rather than having some over-arching bridge
subdirectory maintainer who doesn't have a clue whether the changes
work on the hardware.

IMHO, having bridge driver authors/maintainers look after their own
code has many advantages.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ