[Ksummit-2013-discuss] [ATTEND] maintainer hierarchy vs. the release process

[John W. Linville]

Greetings,

I would like to attend this year's Kernel Summit event.

My proposed discussion topic might be the inverse of Jiri Kosina's
item #4.  I think it is good for us to spread the maintenance burden
farther afield.  This alleviates some of the burdens of patch monkeying
and code review, and it can help to address Steven Rostedt's maintainer
succession concern as well.  But it also introduces interdependencies
for developers across increasingly disparate subsystems.

The trees I maintain are pushed to Linus through Dave Miller.
Feeding me are several driver trees as well as trees for the NFC and
Bluetooth subsystems.  During the 3.10 stream I merged some patches
to which Dave (rightly) objected.  That's No Big Deal, but it did
cause some pain both to me and my feeder maintainers.

Fast forward to the 3.11 merge window...  Dave had merged a patch to
which Linus objected, and Linus refused to pull the net-next tree.
That, too, was resolved quickly.  But it highlights the fact that
disagreement between maintainers closer to the root of the tree effect
developers across all the diverging branches.  If (unlikely as it may
seem) Linus had continued to refuse Dave's pull request, then all of my
downstream trees would have missed 3.11 through no fault of their own.

Obviously, the above is exaggerated or even contrived.  But my
point is only that added hierarchy has potential downsides too.
If we want to go that direction, then we should consider changes to
the release process (e.g. a multi-stage merge window?), and accept
that we might be introducing greater patch latency.  Of course,
that might not always be so bad either...? :-)

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville at tuxdriver.com			might be all we have.  Be ready.