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

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] [day] [month] [year] [list]

Date:	Wed, 10 Jul 2013 16:44:59 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	"Theodore Ts'o" <tytso@....edu>,
	Steven Rostedt <rostedt@...dmis.org>,
	ksummit-2013-discuss@...ts.linuxfoundation.org,
	linux-kernel@...r.kernel.org
Subject: Re: [Ksummit-2013-discuss] [ATTEND] What to do when a maintainer
 is no longer available

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

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