Home_greyopenFATE - openSUSE feature tracking > #306412
Dashboard | Search | Sign up | Login

Please login or register to be able to edit or vote this feature.

Easy and unified way to enable/disable optional/experimental features

Feature state

Hackweek V
Rejected Information
openSUSE Distribution
Rejected Information

Description

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.

Discussion


icons/user_comment.png M. L. wrote: (8 years ago)

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 head.

icons/user_comment.png T. H. wrote: (8 years ago)

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 decisions.

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.

Thanks.

icons/user_comment.png R. M. wrote: (8 years ago)

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. 

icons/user_comment.png S. K. wrote: (8 years ago)

"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.

icons/user_comment.png T. H. wrote: (8 years ago)

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?

icons/user_comment.png S. K. wrote: (8 years ago)

a feature to enable/disable PA _is_ "implementable". I rejected this meta feature for not being implementable

icons/user_comment.png T. H. wrote: (8 years ago)

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. :-(

Last change: 2 months ago
Voting
Score: 2
  • Negative: 1
  • Neutral: 0
  • Positive: 3
Feature Export
Application-xmlXML   Text-x-logPlaintext   PrinterPrint