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
