[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fc9c89f8-0f8d-a31e-ac62-acedc6bd4326@infradead.org>
Date: Tue, 19 Jul 2016 15:46:09 -0700
From: Randy Dunlap <rdunlap@...radead.org>
To: Jonathan Corbet <corbet@....net>,
Mahesh Khanwalkar <maheshkhanwalkar@...il.com>
Cc: sudeep.dutt@...el.com, ashutosh.dixit@...el.com,
tglx@...utronix.de, clemens@...isch.de, wim@...ana.be,
linux@...ck-us.net, gregkh@...uxfoundation.org,
dasaratharaman.chandramouli@...el.com, timur@...eaurora.org,
arnd@...db.de, nab@...ux-iscsi.org, hans.verkuil@...co.com,
mchehab@....samsung.com, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-pcmcia@...ts.infradead.org,
linux-watchdog@...r.kernel.org
Subject: Re: [PATCH v4] Documentation: Move samples from doc to samples/
On 07/19/16 15:35, Jonathan Corbet wrote:
> On Mon, 18 Jul 2016 15:55:00 -0400
> Mahesh Khanwalkar <maheshkhanwalkar@...il.com> wrote:
>
>> Moved sample code found in Documentation/ to samples/ but kept actual
>> documentation where it is, while updating any in-text references to the
>> moved code. Updated the Documentation/Makefile and samples/Makefile to
>> reflect the change. Built with CONFIG_SAMPLES=y in .config with no
>> build errors. The directories added within samples/ still follow the
>> same structure that they did in Documentation. Directories in
>> Documentation/ that contained code still exist, only the code within
>> them has been moved out accordingly.
>
> So, while I'm generally in favor of moving this code over to samples/,
ack that.
> I'm a bit nervous about a single, do-it-all patch. I'd rather see each
> subsystem's stuff moved separately, with (1) review from the appropriate
> maintainer, and (2) some sense that somebody has looked at this code and
> ensured that it still makes sense to keep around.
>
> For example, pcmcia/crc32hash.c predates the git era and has only seen
> trivial changes in living memory. I have this vague sense that the
> number of new PCMCIA cards needing addition is pretty small these days.
> Rather than move it to samples/ (what is it a sample of?), we might want
> to consider just getting rid of it.
That one is not really a sample, it's more of a development/developer tool,
so it should end up in tools/ IMO.
--
~Randy
Powered by blists - more mailing lists