On Mon, 9 Dec 2019 17:06:34 +0000 Will Deacon <will@xxxxxxxxxx> wrote: >On Mon, Dec 09, 2019 at 09:00:57AM -0800, Paul E. McKenney wrote: >> On Mon, Dec 09, 2019 at 09:44:33AM +0000, Will Deacon wrote: >> > On Fri, Dec 06, 2019 at 02:51:56PM -0800, Paul E. McKenney wrote: >> > > On Fri, Dec 06, 2019 at 11:38:22PM +0100, SeongJae Park wrote: >> > > > On Fri, Dec 6, 2019 at 11:08 PM Paul E. McKenney <paulmck@xxxxxxxxxx> wrote: >> > > > > But since Jon seems to be taking these in his capacity and Documentation >> > > > > maintainer, could you please resend CCing him? If we have these changes >> > > > > scattered across too many trees, someone is going to get confused, >> > > > > and it probably will be me. ;-) >> > > > >> > > > Agreed, CC-ing Jon to this mail. That said, this is a followup of Will's >> > > > patch[1] and the patch is also not queued in Jon's tree. So, I would like to >> > > > hear Will's opinion either, if possible. >> > > > >> > > > [1] https://lore.kernel.org/lkml/20191108170120.22331-10-will@xxxxxxxxxx/ >> > > >> > > Ah, this one got caught out in the conversion from .html to .rst. >> > > >> > > I did get an ack on one of those, and thus queued it. I clearly need to >> > > take another look at Will's series, and thank you for the reminder! >> > >> > I was planning to include this in the next posting of my series, but I was >> > waiting for the merge window to close first. Now that we have -rc1, I'll >> > post it this week, although the patches are also queued up in my tree here >> > [1] (warning -- rebasing development branch). >> > >> > I'll leave the patches that are unrelated to smp_read_barrier_depends() to >> > Paul and Jon, unless they indicate a preference to the contrary. >> >> I don't know about Jon, but I might need a reminder as to which patches >> those are. ;-) > >https://lore.kernel.org/lkml/20191121234125.28032-1-sj38.park@xxxxxxxxx > >...but it actually looks like Jon picked those all up, so I think we're good. > >SeongJae -- please shout if we've missed something (the link above, plus >this patch). Sorry for making things too complicated. So, below is the timeline: 2019-11-08 ---------- Will posted a patchset containing a patch removing references to [smp_]read_barrier_depends() from memory-barriers.txt. https://lore.kernel.org/lkml/20191108170120.22331-1-will@xxxxxxxxxx/ 2019-11-21 ---------- I posted a translation of the patch (patchset 1): https://lore.kernel.org/lkml/20191121193209.15687-1-sj38.park@xxxxxxxxx/ 2019-11-22 ---------- I posted another patchset for the Korean translations (patchset 2): https://lore.kernel.org/linux-doc/20191121234125.28032-1-sj38.park@xxxxxxxxx/ 2019-11-26 ---------- Paul queued the `patchset 1` and `patchset 2`. He also asked me to get a review from other Korean, if possible: https://lore.kernel.org/lkml/20191126222004.GV2889@paulmck-ThinkPad-P72/ Same day, Jon queued the `patchset 2` (not `patchset 1`) and noticed the conflict. Paul dropped both `patchset 1` and `patchset 2` from his tree. Maybe this is the start of the confusion. 2019-11-29 ---------- I got a review results from another Korean for both patchset 1 and patchset 2. Because patchset 1 has already merged in Linus's tree, I made another patchset containing fix of the patchset 1 (patchset 1-1): https://lore.kernel.org/linux-doc/20191129182823.8710-1-sjpark@xxxxxxxxx/ Because patchset 2 is not merged in any tree, I made and posted the second version of the patchset 2 (patchset 2-1): https://lore.kernel.org/lkml/20191129180837.7233-1-sjpark@xxxxxxxxx/ So, patchset 1 is already merged by Jon, and patchset 2 is abandoned. Patchset 1-1 is waiting for Jon's review, and patchset 2-1 is merged in Will's tree. Will would send the patchset 2-1 with his patches again in near future. Sorry again for introducing messy confusion and hope this to finally make things clear. If you have any problem, please let me know. > >Will