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

[Paul E. McKenney]

On Wed, Jul 10, 2013 at 04:56:12PM -0400, Steven Rostedt wrote:
> On Wed, 2013-07-10 at 16:45 -0400, Steven Rostedt wrote:
> 
> > 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.
> 
> Bah, spell check failed me. That was suppose to be "momentarily
> incapacitated" not "monumentally" :-p
> 
> Really spell check? You made "momentarially" into "monumentally"?

Hey, it made sense to me, "monument" meaning what it does.  ;-)

Interestingly enough, Linus had a little chat with me on this exact
topic earlier this year, and here are the things that I have been doing
to ease the transition of RCU maintainership.  Don't get me wrong -- I
fully intend to maintain RCU as long as I am able.  On the other hand,
if I am still maintaining RCU fifty years from now, I will be doing so
as a centenarian.  And yes, my ancestors did live reasonably long lives,
but they did not live quite -that- long.  To the many good points raised
elsewhere in this thread, we should keep in mind that whoever will be
maintaining the Linux kernel's RCU implementation in 2063 probably has
not yet been born.  ;-)

That said, I believe that I can still afford to take a long-term view
of this transition.  With that in mind, here are a few things that I
have been doing to make things easier:

o	Getting basic RCU support into language standards.  RCU has
	thus far been relying on non-standard extensions to the C
	language.  The C/C++11 standards include memory_order_consume
	loads, which are intended to support RCU readers.  Standards
	committees being what they are, this feature is not a perfect
	match for the Linux kernel's usage, but on the other hand it
	seems likely that software-engineering considerations will
	continue to evolve the kernel's use of RCU towards the standard.
	I hope that this means that my successors will have at least
	a little less need to fight the compilers.

o	Documentation/RCU/RTFP.txt.  If I write it down, some people
	will read it -- and it doesn't take too many.  I am currently
	stalled on detailed documentation of the current implementation,
	but will get back to it.

o	Introducing RCU to academia.  This is important because many
	of us are taught by academics, so the more coverage of RCU there
	is in university coursework, the larger the pool of potential
	RCU maintainers.  Fortunately, more than 20 major universities
	that I know of devote some time to teaching RCU, a few of which
	have been doing so for more than a decade.  At one of the schools,
	30% of one of your grade on one of the midterms depends on your
	knowledge of RCU.  Even better, most of this has happened without
	my help or even awareness.

o	Encouraging research in the area of RCU.  In fact, the earliest
	things that vaguely resembled RCU were from academic research,
	it is just that for whatever reason they lost interest in it for
	an extended time.  More recent work at Portland State University,
	MIT, Cambridge University, IMDEA, Tel Aviv University, University
	of Toronto, Chennai Mathematical Institute, Oxford University,
	and Queen Mary University has pushed the boundaries of RCU usage
	and of formalization of RCU.  In fact, one upcoming paper tries
	out its formal-verification technique on nothing less than the
	Linux kernel's RCU implementation.

And of course there are several people other than myself who have
contributed code and reviews to the Linux-kernel RCU implementation.

Any other things that I should be doing?

Yes, we are all mortal, but with proper care, that which we create can
persist for a surprisingly long time.  Sometimes even outliving us.  ;-)

							Thanx, Paul