[ATTEND] Discussion: role of the maintainer?

[ATTEND] Discussion: role of the maintainer?

[Myklebust, Trond]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1217 bytes --]

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?

Cheers
  Trond

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: [Ksummit-2012-discuss] [ATTEND] Discussion: role of the maintainer?

[Guenter Roeck]

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

Re: [Ksummit-2012-discuss] [ATTEND] Discussion: role of the maintainer?

[Mark Brown]

On Sat, Jun 16, 2012 at 07:31:19PM +0000, Myklebust, Trond wrote:

> 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?

I mostly agree with Guenter's comments on this, I think that overall
it's much better to give people permission to do more (which naturally
takes off a bit of the load) and let things flow than to try anything
formal.

> 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?

I do sometimes find myself wishing there were more postive things I
could do to say "X is doing an awesome job, you should pay attention to
them/do things like they do/whatever", doing that and saying things
directly to people is good but it's not as discoverable for new
contributors as it might be.  I'm all out of useful ideas for how to do
that, though.