From: SeongJae Park <sj38.park@gmail.com>
To: will@kernel.org
Cc: SeongJae Park <sj38.park@gmail.com>,
Jonathan Corbet <corbet@lwn.net>,
LKML <linux-kernel@vger.kernel.org>,
linux-doc <linux-doc@vger.kernel.org>,
notify@kernel.org, SeongJae Park <sjpark@amazon.de>
Subject: Re: Re: [PATCH v2] Documentation/barriers/kokr: Remove references to [smp_]read_barrier_depends()
Date: Mon, 9 Dec 2019 18:43:07 +0100 [thread overview]
Message-ID: <20191209174307.23698-1-sj38.park@gmail.com> (raw)
In-Reply-To: <20191209170633.GC7489@willie-the-truck> (raw)
On Mon, 9 Dec 2019 17:06:34 +0000 Will Deacon <will@kernel.org> 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@kernel.org> 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@kernel.org/
>> > >
>> > > 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@gmail.com
>
>...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@kernel.org/
2019-11-21
----------
I posted a translation of the patch (patchset 1):
https://lore.kernel.org/lkml/20191121193209.15687-1-sj38.park@gmail.com/
2019-11-22
----------
I posted another patchset for the Korean translations (patchset 2):
https://lore.kernel.org/linux-doc/20191121234125.28032-1-sj38.park@gmail.com/
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@amazon.de/
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@amazon.de/
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
prev parent reply other threads:[~2019-12-09 17:43 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20191121193209.15687-1-sj38.park@gmail.com>
2019-11-29 18:08 ` [PATCH v2] Documentation/barriers/kokr: Remove references to [smp_]read_barrier_depends() SeongJae Park
2019-12-06 17:20 ` SeongJae Park
2019-12-06 20:44 ` Paul E. McKenney
2019-12-06 21:29 ` SeongJae Park
2019-12-06 22:08 ` Paul E. McKenney
2019-12-06 22:38 ` SeongJae Park
2019-12-06 22:51 ` Paul E. McKenney
2019-12-09 9:44 ` Will Deacon
2019-12-09 17:00 ` Paul E. McKenney
2019-12-09 17:06 ` Will Deacon
2019-12-09 17:43 ` SeongJae Park [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191209174307.23698-1-sj38.park@gmail.com \
--to=sj38.park@gmail.com \
--cc=corbet@lwn.net \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=notify@kernel.org \
--cc=sjpark@amazon.de \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox