Mailinglist Archive: opensuse-features (518 mails)

< Previous Next >
[openFATE 306412] Easy and unified way to enable/disable optional/experimental features
  • From: fate_noreply@xxxxxxx
  • Date: Thu, 12 Aug 2010 21:52:46 +0200 (CEST)
  • Message-id: <feature-306412-11@xxxxxxxxxxxxxx>
Feature changed by: jpxviii jpxviii (jpxviii)
Feature #306412, revision 11
Title: Easy and unified way to enable/disable optional/experimental

openSUSE-11.2: Rejected by Stephan Kulow (coolo)
reject date: 2009-06-09 11:45:21
reject reason: technically not possible to implement
Requester: Desirable

+ openSUSE-11.4: Unconfirmed
+ Priority
+ Requester: Important

Requested by: Tejun Heo (teheo)

When new things are introduced, it always generates certain amount of
controversy. It's sometimes due to the quality of the initial
implementation; other times, the feature itself isn't appealing to
large subset of the userbase. Examples of this type of features include
compiz, beagle and pulseaudio.
Given that features which generate a lot of controversies are desktop
related as they are the most visible and that as a distro openSUSE
wants to ship and experiment with new features, having an easy and
unified way to opt in and out of controversial features would resolve a
lot of griefs without harming test coverage too much.
I suggest installing new features by default and ask whether the user
wants to opt in and out of those features from ggreeter. It wouldn't
add another step while still providing choices upfront. Also, the same
selection should be available through control pannel.
This feature would be superset of fate#305296.

#1: Michael Löffler (michl19) (2009-06-02 15:30:26)
I'm kind of split here. On the one hand side an additional opt-in, opt-
out possibility looks useful. On the other hand it adds another step
and most challenging I see the question for what features should get
such a opt-in, opt-out possibility. Fot me it looks more like an over

#2: Tejun Heo (teheo) (2009-06-03 09:33:48) (reply to #1)
It's almost given that we (as most other distros) aren't too stellar at
introducing major new features without breaking a lot of things, so I
think an easy opt in/out mechanism is a necessary compromise rather
than unneeded overhead. After all, in many cases, we do, and kind of
have to do, beta tests in official openSUSE releases.
The selection question is extension of which feature to include and
enable by default, which is a difficult question but something we must
have an answer to anyway. Easy opt in/out will make those decisions
easier for us and our users as we don't have to make full binary
The inclusion criteria should be three - scope (gotta be per-user
desktop stuff), stability and user-preference. All three currently
controversial components - compiz, PA and beagle - satisfy the criteria
pretty nicely.

#3: Rajko Matovic (rajko_m) (2009-06-04 18:51:13) (reply to #2)
Just to agree. We need that choice during installation badly:* We can't
know how experienced are users, ie. what kind of trouble they can
handle (if any) * nor what they want, stable daily use system for
granny, or bleeding edge for testing, or both where reboot, or
logout/login cures breakage introduced with buggy program IMHO, kernel
has such options included for ages, and they worked fine. It may
require to rethink current software delivery model, where we have 1
package per product, to one that will allow 2 or more versions
installed concurently. 

#4: Stephan Kulow (coolo) (2009-06-09 11:48:07)
"new things" are very seldomly packages or environment variables. This
feature can't be "implemented" because it's a policy you ask for. And
we'll continue to do such decisions case by case.
new things: kernel 2.6.30? want to revert from ggreeter? compiled with
gcc 4.4? revert from ggreeter? kde4? want to revert to 11.0? I could
continue with cases.

#5: Tejun Heo (teheo) (2009-06-09 19:09:26) (reply to #4)
Please don't go overboard. "New things" doesn't mean mathmatically
complete set of new things. It means new things whose usefulness or
stability is still debatable and in many cases those things are
optional. Do you seriously think backing down from gcc-4.4 and
enabling/disabling PA are on the same scale of technical difficulty?
Rejecting is fine but please do it with a valid reason. Turning off PA
from ggreeter is technically infeasible? Really?

#6: Stephan Kulow (coolo) (2009-06-09 12:20:16) (reply to #5)
a feature to enable/disable PA _is_ "implementable". I rejected this
meta feature for not being implementable

#7: Tejun Heo (teheo) (2009-06-09 19:26:32) (reply to #6)
Let's then modify the description to "easy way to enable/disable
controversial per-desktop features which can be enabled/disabled
easily". I think it's pretty obvious already tho. :-(

openSUSE Feature:

< Previous Next >
This Thread