Received-SPF: pass (google.com: domain of linux-kernel+bounces-88309-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Fri, 1 Mar 2024 12:04:29 +0100
From: Nicolas Schier <n.schier@avm.de>
To: Sergey Senozhatsky <senozhatsky@chromium.org>
Cc: Masahiro Yamada <masahiroy@kernel.org>, linux-kbuild@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCHv2] kconfig: add some Kconfig env variables to make help
Message-ID: <ZeG2PRYmdO0r44kS@buildd.core.avm.de>
Mail-Followup-To: Sergey Senozhatsky <senozhatsky@chromium.org>,
	Masahiro Yamada <masahiroy@kernel.org>,
	linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org
References: <20240222032559.496127-1-senozhatsky@chromium.org>
 <CAK7LNARo4L6qxoqRU-0dgABarukJKAaZpCRtfA3MyUHhSuDQxQ@mail.gmail.com>
 <20240222051621.GH11472@google.com>
 <20240228045652.GH11972@google.com>
 <CAK7LNAQ8OyNMeGzVoTRg-sHDZ4YK0EKY_eEWNepekaibO_ZKwg@mail.gmail.com>
 <20240229021010.GM11972@google.com>
 <CAK7LNASujf8m4PpMyoCC1cTN_YGeG1HVaOR+3pZx5=3OJp=85A@mail.gmail.com>
 <20240229034739.GN11972@google.com>
 <CAK7LNAS-mOxY884pLEMwWaX+wgzXdc6+=vqN=wfHBekuKL5ryA@mail.gmail.com>
 <20240301043316.GO11972@google.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20240301043316.GO11972@google.com>
Organization: AVM GmbH

On Fri, Mar 01, 2024 at 01:33:16PM +0900, Sergey Senozhatsky wrote:
> On (24/03/01 00:35), Masahiro Yamada wrote:
> > > >   "I am interested only in these. I do not care about the rest,
> > >
> > > It's "I *do NOT know* what the rest do".  I cannot document something
> > > that I have no knowledge of, can I?  So as a reasonable start I added
> > > only those that I'm familiar with (and I have explicitly stated that
> > > in previous emails), and I disagree with the "bad attitude" label.
> > 
> > 
> > You were aware of:
> > 
> >  - several env variables are listed in the document
> >  - your patch would introduce a new "inconsistency"
> >  - somebody else would need to make efforts to solve it
> 
> OK.
> 
> > > So the rational for that was that people run "make help" and find
> > > out about new build targets, for instance, but there is no way for
> > > people to find out about new Kconfig features (and yes, we are talking
> > > "new features" here) that are controlled by env variables.  We need
> > > to do something about it, don't you agree?
> > 
> > Disagree.
> > 
> > I maintain the entire Kconfig, not like you only caring about
> > a particular feature.
> > 
> > If you add only two in help, I have no idea about
> > what it will look like in the end.
> > I am not convinced that it will be in good shape.
> > So, it is reasonable for me to reject it.
> 
> Yes, OK.  I wasn't talking about this patch in particular at that
> point, I was more curious whether you agreed that we need to document
> in some way those vars in `make help` or not.  If you see value in
> documenting them then I can sit down and try to come up with v3 that
> will (in one way or another) give a simple "help" description for
> each of Kconfig's vars.

Perhaps it might be a compromise to let 'make help' point to the
kbuild/kconfig documentation?

Kind regards,
Nicolas