Messages in this thread | | | Date | Mon, 25 Jun 2018 13:43:49 -0700 | From | "Paul E. McKenney" <> | Subject | Re: Proposed changes to -rcu workflow |
| |
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
| |