From: Sergey Senozhatsky <senozhatsky@chromium.org>
To: Masahiro Yamada <masahiroy@kernel.org>
Cc: Sergey Senozhatsky <senozhatsky@chromium.org>,
linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCHv2] kconfig: add some Kconfig env variables to make help
Date: Fri, 1 Mar 2024 13:33:16 +0900 [thread overview]
Message-ID: <20240301043316.GO11972@google.com> (raw)
In-Reply-To: <CAK7LNAS-mOxY884pLEMwWaX+wgzXdc6+=vqN=wfHBekuKL5ryA@mail.gmail.com>
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.
next prev parent reply other threads:[~2024-03-01 4:33 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-22 3:12 [PATCH] kconfig: add some Kconfig env variables to make help Sergey Senozhatsky
2024-02-22 3:18 ` Sergey Senozhatsky
2024-02-22 3:25 ` [PATCHv2] " Sergey Senozhatsky
2024-02-22 4:57 ` Masahiro Yamada
2024-02-22 5:16 ` Sergey Senozhatsky
2024-02-28 4:56 ` Sergey Senozhatsky
2024-02-29 2:03 ` Masahiro Yamada
2024-02-29 2:10 ` Sergey Senozhatsky
2024-02-29 3:36 ` Masahiro Yamada
2024-02-29 3:47 ` Sergey Senozhatsky
2024-02-29 15:35 ` Masahiro Yamada
2024-03-01 4:33 ` Sergey Senozhatsky [this message]
2024-03-01 11:04 ` Nicolas Schier
2024-03-01 14:28 ` Sergey Senozhatsky
2024-03-04 6:41 ` Nicolas Schier
2024-03-05 16:46 ` Masahiro Yamada
2024-03-09 20:24 ` Nicolas Schier
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=20240301043316.GO11972@google.com \
--to=senozhatsky@chromium.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masahiroy@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