Proposed changes to -rcu workflow

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

Re: Proposed changes to -rcu workflow

[Paul E. McKenney]

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