> >> > Let me ask a dumb question: Why cannot one of the maintaners pull > the > >> > commit from the other mainainer's git repo directly? IE why have this > >> > third trusted/signed git repo that has to be on k.o, from which both > >> > maintainers pull? If one of you can pull it in via a patch series, > >> > like you do for all other patches, and then notify the other > >> > maintainer to pull it from the first maintainers' repo if the series > >> > meets the requirements that it needs to be in both maintainers' > >> > repositories? This avoids adding more staging git repos on k.o. But > >> > probably I'm missing something... > >> > >> Tree A may not want all of tree B's changes, and vice versa. > > > > I was thinking the special commit would go into a branch that was based > on, > > say rc1 or rc2 of one of the maintainers. Then both maintainers pull that > > into their -next branch. Would that work? > > That makes things more complicated. For the maintainers, yes. But it avoids setting up k.o accounts and git repos for each device driver maintainer that has this issue. > > The simplest design is that "identical" commits end up in both the > RDMA and the net-next tree. > > Then it absolutely doesn't matter whose tree goes into Linus's first. > Yes, and that would still be the case, from my understanding: Instead of each driver having a k.o. signed git repo, we ask the maintainers to stage this common branch that both maintainers pull from into their -next branches/repos. > Also, we should not be merging "merge window" code after -rc1. "-rc1" > means the merge window is closed. I meant using rc-1 for the current release when submitting these shared commits for the _following merge window_. Steve. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
