Re: Proposed changes to -rcu workflow

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

On Fri, Jun 22, 2018 at 02:26:15PM -0700, Paul E. McKenney wrote:
> 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?

Hearing no objections, I have rebased as described above.  The -rcu
branch "dev" now includes both LKMM and RCU changes.

							Thanx, Paul