Re: Re: [PATCH v2] Documentation/barriers/kokr: Remove references to [smp_]read_barrier_depends()
From: SeongJae Park
Date: Mon Dec 09 2019 - 12:43:22 EST
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