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]
Date:	Sat, 16 Jun 2012 18:13:21 -0700
From:	Guenter Roeck <linux@...ck-us.net>
To:	"Myklebust, Trond" <Trond.Myklebust@...app.com>
Cc:	"ksummit-2012-discuss@...ts.linux-foundation.org" 
	<ksummit-2012-discuss@...ts.linux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [Ksummit-2012-discuss] [ATTEND] Discussion: role of the
 maintainer?

On Sat, Jun 16, 2012 at 07:31:19PM +0000, Myklebust, Trond wrote:
> Hi,
> 
> This is a spin off from the discussion topic that was started by Thomas
> Gleixner. I'd like to turn this into a full discussion on the role of
> the Linux Maintainer.
> 
> Currently, the Linux maintainer appears to be responsible for filling
> all of the traditional roles of software architect, software developer,
> patch reviewer, patch committer, and software maintainer.
> 
> My question is whether or not there might be some value in splitting out
> some of these roles, so that we can assign them to different people, and
> thus help to address the scalability issues that Thomas raised? For
> instance, would it be useful to have a separate 'software maintainer'
> role for dealing with post-merge issues, such as ensuring that bugs and
> regressions get fixed by someone?
> If so, how do we ensure that people get credit for the roles that they
> assume? Should we perhaps add additional entries to the MAINTAINERS file
> for some of these responsibilities?
> 
Having more than one maintainer works well for the hwmon subsystem. It is a good
way to "train" new maintainers.

I don't like the idea of formalizing maintainer's responsibilities, and I don't
see the need to do it. It should be up to the maintainers to decide and work out
which role to take; there are multiple ways to split the work, roles may change
over time, and the maintainers are the best to decide what their role should be.

And when it comes to architects, my personal opinion is that every architect
should also implement code, to not forget what it actually takes to do it.

Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ