Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230114-doc-v1-1-efec2689e423@pefoley.com> <87edrxgk25.fsf@meer.lwn.net>
In-Reply-To: <87edrxgk25.fsf@meer.lwn.net>
From:   Peter Foley <pefoley2@pefoley.com>
Date:   Sun, 15 Jan 2023 16:42:05 -0800
Message-ID: <CAOFdcFNKJacBVtrV-hJyUu6hKBVFaKdpA84cZ6WGnZ=ZGnb4kQ@mail.gmail.com>
Subject: Re: [PATCH] Documentation: Avoid duplicate Kconfig inclusion
To:     Jonathan Corbet <corbet@lwn.net>
Cc:     Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
        linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Sat, Jan 14, 2023 at 8:25 AM Jonathan Corbet <corbet@lwn.net> wrote:
> The duplicate inclusion does seem worth fixing, but I wonder if you're
> deleting the right one?  Having the documentation Kconfig under lib
> seems a bit strange, somehow; Documentation/ is a top-level directory,
> after all.

I thought about that.
Looking at the history, the toplevel inclusion was added in
b1663d7e3a7961 (2019-06-04), and the lib/Kconfig.debug inclusion was
added in 75442fb0ccaacd (2020-10-30).
Given the actual entries in Documentation/Kconfig
(WARN_MISSING_DOCUMENTS and WARN_ABI_ERRORS), putting them under the
"Kernel hacking" menu makes sense to me.
We *could* add a new top-level menu to Documentation/Kconfig, but it
doesn't really seem like an improvement over having them live in
Kernel hacking.