Re: [Ksummit-2013-discuss] [ATTEND] What to do when a maintainer is no longer available

Re: [Ksummit-2013-discuss] [ATTEND] What to do when a maintainer is no longer available

[Theodore Ts'o]

(Reminder: please cc the relevant mailing lists when proposing a topic
for the kernel summit.)

On Wed, Jul 10, 2013 at 04:45:51PM -0400, Steven Rostedt wrote:
> Recently we lost a major Open Source developer to a tragic accident.
> Seth Vidal wasn't a kernel developer, but his death reminds us of how
> any one of us can leave this planet at any time. The end of last year, a
> major kernel maintainer had an accident that caused him to leave the
> community for several months.
> 
> As with all Open Source projects, the Linux kernel is not a product from
> a company, but it comes from a community. A community made up of people,
> where a single person has large control over vital parts of the kernel.
> Some parts of the kernel is held by several people, but there are
> several people that I could imagine would cause severe disruption if
> something were to happen to them. Do we all have backups that can take
> over if something unexpected happen to us?
> 
> We are not getting any younger. Life's reality is that we can perish at
> any time. I would like to discuss ways that we can help the community to
> move forward in case something happens to any one of us.
> 
> Perhaps we should all have someone as a backup? Let others know who you
> trust to work as the maintainer if something were to happen to you. We
> can have limits to what that person can do in case you are still around
> but only monumentally incapacitated.

I agree this is an important thing to do, but I'm hesitant about
having someone formally annointed as "the successor".  Information in
the MAINTAINERS file can get stale, and removing someone who may not
have as much time, and so has become a bit inactive, and replacing him
or her with someone who might be more active, is a political act which
can cause feelings to be hurt or otherwise lead to drama.

It's for the same reason that we don't have a formally designated
"core team", although people have a pretty good idea who the core
developers are.

That being said, maintainers would be well advised to make sure there
are other people who know enough that they could take over if
something unfortunate happens, and there are a number of ways helping
that process along, including delegating as much as possible in terms
of code reviews, etc., to other subsystem developers.

> I rather have something in place before it happens. Unfortunately, it
> will happen. It's just a matter of time.

It's happened already; for example, when Leonard Zubkoff passed
away in an unfortunate helicopter accident.

   		       	  		  - Ted

> 
> -- Steve
> 
> 
> _______________________________________________
> Ksummit-2013-discuss mailing list
> Ksummit-2013-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-2013-discuss

Re: [Ksummit-2013-discuss] [ATTEND] What to do when a maintainer is no longer available

[H. Peter Anvin]

On 07/10/2013 03:22 PM, Theodore Ts'o wrote:
> 
> I agree this is an important thing to do, but I'm hesitant about
> having someone formally annointed as "the successor".  Information in
> the MAINTAINERS file can get stale, and removing someone who may not
> have as much time, and so has become a bit inactive, and replacing him
> or her with someone who might be more active, is a political act which
> can cause feelings to be hurt or otherwise lead to drama.
> 
> It's for the same reason that we don't have a formally designated
> "core team", although people have a pretty good idea who the core
> developers are.
> 
> That being said, maintainers would be well advised to make sure there
> are other people who know enough that they could take over if
> something unfortunate happens, and there are a number of ways helping
> that process along, including delegating as much as possible in terms
> of code reviews, etc., to other subsystem developers.
> 
>> I rather have something in place before it happens. Unfortunately, it
>> will happen. It's just a matter of time.
> 
> It's happened already; for example, when Leonard Zubkoff passed
> away in an unfortunate helicopter accident.
> 

I agree with Ted here... this has not in general been a huge problem
(neither with untimely death nor with other reasons to depart the kernel
community.)  In some ways we are much worse off with the "hanger-on":
the maintainer who is still "officially" in charge but not doing what is
needed.  From personal experience I can say that that phenomenon gets
even worse for the "designated successor" scenario: as the "designated
successor" isn't actually doing the work, it is not at all clear that
they will be capable of shouldering the burden at the particular time
the main maintainer departs.  I had a (non-kernel, but Open Source)
project where I made the mistake of appointing a successor, and found
that the successor in effect prevented anything useful from getting
done... just not enough pressure to not fork the project, and so it died
a long, slow death.  Five years later there still was not a new release,
and no one was interested in the project anymore.

	-hpa