Proposed changes to -rcu workflow

[Paul E. McKenney]

Hello!

I am proposing changes to how I set up my -rcu tree:

	The -rcu tree also takes LKMM patches, and I have been handling
	these completely separately, with one branch for RCU and another
	for LKMM. But this can be a bit inconvenient, and more important,
	can delay my response to patches to (say) LKMM if I am doing (say)
	extended in-tree RCU testing. So it is time to try something a
	bit different.

	My current thought is continue to have separate LKMM and RCU
	branches (or more often, sets of branches) containing the commits
	to be offered up to the next merge window. The -rcu branch lkmm
	would flag the LKMM branch (or, more often, merge commit) and
	a new -rcu branch rcu would flag the RCU branch (or, again more
	often, merge commit). Then the lkmm and rcu merge commits would
	be merged, with new commits on top. These new commits would be
	intermixed RCU and LKMM commits.

	The tip of the -rcu development effort (both LKMM and RCU)
	would be flagged with a new dev branch, with the old rcu/dev
	branch being retired. The rcu/next branch will continue to mark
	the commit to be pulled into the -next tree, and will point to
	the merge of the rcu and lkmm branches during the merge window.

	I will create the next-merge-window branches sometime around
	-rc1 or -rc2, as I have in the past. I will send RFC patches to
	LKML shortly thereafter. I will send a pull request for the rcu
	branch around -rc5, and will send final patches from the lkmm
	branch at about that same time.

Thoughts?

							Thanx, Paul