From: Dave Jones <davej@redhat.com>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: Kees Cook <keescook@chromium.org>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Remove CONFIG_EXPERIMENTAL
Date: Tue, 28 Aug 2012 15:25:27 -0400 [thread overview]
Message-ID: <20120828192527.GA9921@redhat.com> (raw)
In-Reply-To: <CAFtxgO5QSYwQcHCbaXoT6pauTYPGpNBC31vufcAOUb5i7c-UfA@mail.gmail.com>
On Tue, Aug 28, 2012 at 10:10:48AM -0400, Jeff Garzik wrote:
> On Mon, Aug 27, 2012 at 5:53 PM, Kees Cook <keescook@chromium.org> wrote:
> > This config item has not carried much meaning for a while now and is
> > almost always enabled by default. Remove it and adjust various config
> > logic and documentation.
>
> It does have meaning... !CONFIG_EXPERIMENTAL means more stable. In
> the past things would get CONFIG_EXPERIMENTAL until they've been tried
> in the field or otherwise hit some goal in the developer's mind.
>
> Is this a practical distinction? Probably not, as the markers often
> go unmaintained...
That's exactly the point. We have 'experimental' code that's been marked
as such for 10-15 years. Maturity has nothing to do with that option,
even if that was its original intention.
The reality seems to be that near everyone sets EXPERIMENTAL because
there's so much stuff tucked behind it, that they want at least some of it.
They aren't choosing this option because they care about how mature the
code is, they're setting it because they *need* something that it's hidden behind.
What *might* be a more useful thing, is instead of adding new options
depending on EXPERIMENTAL, introduce something like CONFIG_NEW_IN_3_6
(and a release or so later, when it's not considered new any more,
drop it). But I'm not convinced that even this wouldn't succumb to
the same neglect that EXPERIMENTAL has.
Dave
prev parent reply other threads:[~2012-08-28 19:29 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-27 21:53 [PATCH] Remove CONFIG_EXPERIMENTAL Kees Cook
2012-08-28 4:23 ` Rusty Russell
2012-08-28 14:10 ` Jeff Garzik
2012-08-28 19:25 ` Dave Jones [this message]
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=20120828192527.GA9921@redhat.com \
--to=davej@redhat.com \
--cc=jgarzik@pobox.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.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