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
