Re: [RFC: 2.6 patch] let GROUP_SCHED depend on BROKEN

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Mike Galbraith
Date: Tuesday, May 27, 2008 - 2:47 am

On Tue, 2008-05-27 at 11:58 +0300, Adrian Bunk wrote:


FWIW, here's my NAK, and the grounds therefore:  Group scheduling
clearly fits the current criteria for CONFIG_EXPERIMENTAL.  In-tree
development is a necessary fact of life, and has always been a fact of
life.  IMO, your attempt to change the rules is seriously misguided.

<quote>
config EXPERIMENTAL
	bool "Prompt for non-development and/or absolutely complete code/drivers"
	---help---
	  Some of the various things that Linux supports (such as network
	  drivers, file systems, network protocols, etc.) can be in a state
	  of development where the functionality, stability, or the level of
	  testing is not yet high enough for general use. This is usually
	  known as the "alpha-test" phase among developers. If a feature is
	  currently in alpha-test, then the developers usually discourage
	  uninformed widespread use of this feature by the general public to
	  avoid "Why doesn't this work?" type mail messages. However, active
	  testing and use of these systems is welcomed. Just be aware that it
	  may not meet the normal level of reliability or it may fail to work
	  in some special cases. Detailed bug reports from people familiar
	  with the kernel internals are usually welcomed by the developers
	  (before submitting bug reports, please read the documents
	  <file:README>, <file:MAINTAINERS>, <file:REPORTING-BUGS>,
	  <file:Documentation/BUG-HUNTING>, and
	  <file:Documentation/oops-tracing.txt> in the kernel source).

	  This option will also make obsoleted drivers available. These are
	  drivers that have been replaced by something else, and/or are
	  scheduled to be removed in a future kernel release.

	  Unless you intend to help test and develop a feature or driver that
	  falls into this category, or you have a situation that requires
	  using these features, you should probably say N here, which will
	  cause the configurator to present you with fewer choices. If
	  you say Y here, you will be offered the choice of using features or
	  drivers that are currently considered to be in the alpha-test phase.
</quote>

	-Mike

--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[RFC: 2.6 patch] let GROUP_SCHED depend on BROKEN, Adrian Bunk, (Tue May 27, 1:58 am)
Re: [RFC: 2.6 patch] let GROUP_SCHED depend on BROKEN, Mike Galbraith, (Tue May 27, 2:47 am)
Re: [RFC: 2.6 patch] let GROUP_SCHED depend on BROKEN, Mike Galbraith, (Tue May 27, 3:04 am)
Re: [RFC: 2.6 patch] let GROUP_SCHED depend on BROKEN, Adrian Bunk, (Tue May 27, 3:26 am)
Re: [RFC: 2.6 patch] let GROUP_SCHED depend on BROKEN, Mike Galbraith, (Tue May 27, 4:27 am)
Re: [RFC: 2.6 patch] let GROUP_SCHED depend on BROKEN, Peter Zijlstra, (Tue May 27, 4:47 am)
Re: [RFC: 2.6 patch] let GROUP_SCHED depend on BROKEN, Adrian Bunk, (Tue May 27, 6:08 am)
Re: [RFC: 2.6 patch] let GROUP_SCHED depend on BROKEN, Peter Zijlstra, (Tue May 27, 7:17 am)
Re: [RFC: 2.6 patch] let GROUP_SCHED depend on BROKEN, Ingo Molnar, (Tue May 27, 7:22 am)
Re: [RFC: 2.6 patch] let GROUP_SCHED depend on BROKEN, Thomas Gleixner, (Tue May 27, 10:30 am)
Re: [RFC: 2.6 patch] let GROUP_SCHED depend on BROKEN, Adrian Bunk, (Tue May 27, 10:53 am)
Re: [RFC: 2.6 patch] let GROUP_SCHED depend on BROKEN, Mike Galbraith, (Tue May 27, 11:17 am)
Re: [RFC: 2.6 patch] let GROUP_SCHED depend on BROKEN, Adrian Bunk, (Tue May 27, 12:18 pm)