[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190416203114.GB25517@roeck-us.net>
Date: Tue, 16 Apr 2019 13:31:14 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: Jonathan Corbet <corbet@....net>
Cc: Mauro Carvalho Chehab <mchehab+samsung@...nel.org>,
Linux Doc Mailing List <linux-doc@...r.kernel.org>,
Mauro Carvalho Chehab <mchehab@...radead.org>,
linux-kernel@...r.kernel.org, Andrew Jeffery <andrew@...id.au>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Jean Delvare <jdelvare@...e.com>,
Joel Stanley <joel@....id.au>,
linux-arm-kernel@...ts.infradead.org,
linux-aspeed@...ts.ozlabs.org, linux-hwmon@...r.kernel.org,
linuxppc-dev@...ts.ozlabs.org, Liviu Dudau <liviu.dudau@....com>,
Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
Michael Ellerman <mpe@...erman.id.au>,
Paul Mackerras <paulus@...ba.org>,
Sudeep Holla <sudeep.holla@....com>
Subject: Re: [PATCH v2 00/21] Convert hwmon documentation to ReST
On Tue, Apr 16, 2019 at 02:19:49PM -0600, Jonathan Corbet wrote:
> On Fri, 12 Apr 2019 20:09:16 -0700
> Guenter Roeck <linux@...ck-us.net> wrote:
>
> > The big real-world question is: Is the series good enough for you to accept,
> > or do you expect some level of user/kernel separation ?
>
> I guess it can go in; it's forward progress, even if it doesn't make the
> improvements I would like to see.
>
> The real question, I guess, is who should take it. I've been seeing a
> fair amount of activity on hwmon, so I suspect that the potential for
> conflicts is real. Perhaps things would go smoother if it went through
> your tree?
>
We'll see a number of conflicts, yes. In terms of timing, this is probably
the worst release in the last few years to make such a change. I currently
have 9 patches queued in hwmon-next which touch Documentation/hwmon.
Of course the changes made in those are all not ReST compatible, and I have
no idea what to look out for to make it compatible. So this is going to be
fun (in a negative sense) either way.
I don't really have a recommendation at this point; I think the best I could
do to take the patches which don't generate conflicts and leave the rest
alone. But that would also be bad, since the new index file would not match
reality. No idea, really, what the best or even a useful approach would be.
Maybe automated changes like this (assuming they are indeed automated)
can be generated and pushed right after a commit window closes. Would
that by any chance be possible ?
Guenter
Powered by blists - more mailing lists