BrainStorming Prague

From openSUSE

About

This page contains feedback we have collected on one winter afternoon in the Prague SUSE office. The goal was to identify which parts are really good in openSUSE as well as areas, which would need a bit of improvement. And of course, people are eager helping to address those. As a result, this is very subjective view given by people actively working on the openSUSE distribution.

Rules for modifying this page:

• Please, do not add additional topics to the page, this is neither a wishlist, nor feature list, nor most annoying bugs :-). The list of issues should be fixed. The page serves as a starting point for us to understand where we improved, where not and where to start.
• Page has been divided into three sections
  • Open Issues - Issues with incomplete description or waiting for being requested in openFATE or waiting for being selected by somebody to work on. Please, add more description, examples, possible solutions, ideas, and/or create a separate page for them if there is already too much information.
  • In Progress - Issues requested in openFATE or if somebody works on them. Please, join the team, contact the already listed ones, add yourself into Interested in a particular feature.
  • Done - Celebrate :) ;)

We encourage anyone who is interested to address the issues to contact people in the Interested part of each topic.

Pluses

Also, we encourage the openSUSE marketing team to check out the positive Pluses page page that contains a list of areas where openSUSE already shines. Might be a good food for thought as well.

Minuses

Open Issues

The issues that are waiting for someone to address them.

Unclear goals of the project

• results in strange choice of default setup (sometimes bleeding edge, sometimes very conservative)
• As we have SLES and SLERT with totally differrent goals, we can have something like conservative and bleeding-edge opensuse. It's about a few options during compilation something, I mean /*ehamera*/. Is someone able to make estimation how much work it needs?
• openSUSE has been identified as a Smart choice for Linux beginners

Resolution: See Project Overview for the goals of the project.
- This does not address the above concern about having a stable release and a bleeding edge release.
- actually, the Project Overview doesn't say anything, it's business-talk. what's "Provide an environment for open source collaboration that makes openSUSE the world's best Linux distribution for new and experienced Linux users." supposed to mean, precisely?
- Also see OpenSUSE_Distribution_Focus
Tags: communication, long-term
Interested: Lukas Ocilka, Steven Harms

Missing supported scenarios (use cases)

• What is supported, what is not, what should work, what might not
• Manage user expectations
• Focus for the particular release
• Partially conflicts with the "golden cage" problem if not done properly (see below the "golden cage" point)

Tags: communication, long-term
Interested: Milan Vančura

Marking packages as rock-stable/experimental, suggested

• Help user with the choice, clearly indicate preferred choice (mailer, web browser, ...), allow easy choice
• Could be done also for repos, add-on products on higher level
• User typically needs rock-stable system for work with one or two bleeding-edge applications. He can accept when his one unstable bleeding-edge application segfaults every 5 minutes, but if mail client, instant messenger and text editor do something similar, it is not acceptable. Definitelly.
  • It can maybe enslow testing of our distro in community. But it is short term problem only. Users will not leave our distro to more stable. And user is ready to report bugs in one special application he really needs, but a lot of users aren't ready to report every collapsing application and testing a lot of things and do much work around.
• We can use differrent application as stable and different as experimental => easy. But we should use the same application but with differrent version because we will like to use today's experimental as tommorrow's stable => hard. Is yast/zypper ready for that? Can we have more than one version of library? Or should we have these rockstable linked statically?
• This could be integrated into Software Portal and later (when ratings are available) to YaST
• It could be also possible to install something like "complete rock-stable desktop" without evaluating every single application: User might not be really interested in choosing the right browser, IM client and so one... anything that just works might be good enough.

Tags: community, usability, hard
Interested: ehamera, anicka, jdluhos

Slow/unstable applications

• Not clear how to identify which ones, what are the areas to focus on and how to address these
  • jdluhos: we need examples of typical use cases; developers using Factory on their workstations (as proposed earlier) would be a good starting point
  • jdluhos: some crucial apps are already known: web browser, mail client, IM client, terminal, text editor, office package, multimedia player
  • ehamera: it can be workarounded via marking packages as stable/unstable. People will use the stable (older) ones if they has enough functionality.
• Rating of applications could also be integrated into Software Portal and later (when ratings are available) to YaST

Tags: hard, long-term, usability
Interested: Michal Hrusecky, jdluhos

Low-level system performance

• Some decisions in the kernel config are good for servers but are killing desktop performance
  • Significant speed penalty for running a paravirtualized kernel on bare hardware - will be fixed for 11.1 through online update soon
  • IPv6 reported to slow down network for non-IPv6 home users; need to alleviate this
  • Need to systematically compare speed against other distros and ring an alarm if we are significantly slower
  • See also: feature request #305694 - separate desktop/server kernels

Tags: usability
Interested: jdluhos

Configuration of the system (files in /etc, ...) is very complex, hard to understand, layered, ...

• E.g. cron daily
• All services can be started/stopped by /etc/init.d/name_of_service (or rcname_of_service in suse), but our firewall has /etc/init.d/SuSEfirewall2_init, /etc/init.d/SuSEfirewall2_setup and command SuSEfirewall (without rc at start). That's very non-intuitive.
  • there is rcSuSEfirewall2 symlink to /etc/init.d/SuSEfirewall2_setup
• If a configuration is changed automatically (e.g. via YaST), there is no way how to avoid that if user does not want to
• mvancura: configuration (in /etc) can't be changed automatically and comments like "don't edit this file manually, it is maintained by the utility FOO" should be reported as serious bugs. Even a package upgrade or reinstallation must take care of manual changes (example of rules). "In /etc, sysadmin is more than God."
• mvancura: if any automatic change in conffiles is needed, sysadmin should be warned and system must allow him to take a proper action (like a merge of changes)
• anicka: Well written manpage about init script (with information about what environmental variables it uses, what configuration files it reads...) could often help a lot to the admin. When our init script has to be complex, it still could be at least well documented.

Tags: long-term, community, documentation, usability
Interested: ehamera, Michal Hrusecky, Petr Uzel, Milan Vančura, anicka, jdluhos

Small community

The distro is not friendly to people who want to go behind the supported scenarios. As a result, we are losing especially potential contributors. The reasons behind this fact, are (as we think):

• many decisions done behind closed doors: internal build service, pdb not accessible out of Novell, community members not allowed to add a package to Factory themselves (hopefully Contrib would help here)
• poor documentation about packaging and other internal processes out of Novell; [opensuse-packaging] is a discussion about better documentation (mvyskocil)
• vpelcak: it would good if opensuse.org could host small projects of users in svn or git
• this problem depends tightly on 'Hacker unfriendly distro' and 'golden cage problem', for example:
  • openSUSE is easy to start with and eye-candy but hard to modify to one's personal needs as the eye-candiness needs a complicated configuration and there is no basic configuration (not so eye-candy) one can get
  • openSUSE is too different from the upstream very often, not talking about UN*X in general (and same for SLE* as they are based on openSUSE)

Full content was moved to BrainStorming_Prague/Small_Community.

Tags: community, hard, long-term, communication, documentation
Interested: mvyskocil, Milan Vančura, anicka, jdluhos

Our maintenance updates are of low quality, especially descriptions, ...

(by User:Mvidner)

• The description text has no structuring even though it often contains list items. (As seen in this screenshot of KDE Updater Applet) (compare with aptitude screenshot). There is a bug for this see 461206.
  • MasterPatricko: While I agree with your point you are comparing two different dialogs with different purposes in your example: the way YaST displays an RPM changelog has formatting and structure similar to the aptitude changelog you showed above; the kupdateapplet description is not the full changelog.
• There should be clickable links to Bugzilla and CVE for those who want to know more. (We have the info, but it is hidden, as usual. Did you know the index of SUSE Updates by CVE ID?)
• anicka: We need also guidelines for developers who are writing patchinfos. When we do it now, we even might have no idea how the information will be presented to the user at the end.

Tags: Documentation, Process, Easy
Interested: mvyskocil, Michal Čihař, anicka

Too complex for users to handle bugzilla and bug reports

• apport, offline bug-filling
• Crash Catcher
• A lot of people have no idea there is bugzilla
  • typically, when some application crashes, apport should start up, ask user whether he wishes to send in report of failure. Then would be needed data gathered, window with web browser pop up with request to log into it, then would form appear with most fields filled in. User would be expected only to fill in circumstances under which crash happened. Data gathered by apport would be automatically uploaded.
  • As would be also name of bugreport filled in automatically, duplicated bugreports could be easily grouped together and thus eliminated.
  • It would also help to have an application for bugreporting accessible in the KDE/GNOME menu. Advanced user could choose there one of the installed packages to report against, less advanced user could choose from his application menu. He would be asked to fill in his e-mail, the bug would be reported, account created, password sent... and the rest solved through bugzilla like usually. We could probably gather much more reports this way.

Tags:
Interested: matejcik, anicka, Lukas Ocilka

openSUSE web sites not consistent, unclear structure

• the www.opensuse.org page is the intuitive entry point; anything what is linked from there is difficult to find
  • it should contain large, well visible links to all other basic sites (current state: Buildservice link is perfect; link to blogs exists but is almost invisible, links to openFate, bugzilla, the Contrib project, etc. are missing)
  • what about adding an integrator for blogs and news? (better community feeling)
  • the page could easily be made more interactive; what about adding applets for quick messages to developers, links for easy adding openSUSE bugs to bugzilla, voting for applications and bugs...
  • mvyskocil: it's not only about a web site, but also there are many mailing lists and it's hard to find a proper one, because no one is in all lists. (for example opensuse-packaging vs. opensuse-buildservice - it's unclear in many cases, which list should be used).
  • MasterPatricko: The openSUSE Website is the default homepage for all openSUSE users. Any feature changes/additions to it should be considered VERY carefully especially taking into account low-bandwidth users; as it is currently is just about acceptable.

Tags: community, documentation, hard, long-term
Interested: mvyskocil, jdluhos

Too little focus on usability

Where usability means how easily can the user understand and control a particular application. See Usability

• installer is rather good but that's where it stops
  • many small hurdles later: typical example is yast window with warning "All the changes will be lost" when you did not edit anything and want just to close the window.
• most open-source application usability is bad
  • because the apps are written by hackers who don't care that much about usability
  • we could try to convince upstream or the community to look at it?
• still not enough of it

Tags: usability, hard, long-term, community
Interested: matejcik

Too many SUSE-specific solutions which are not upstream

• Typically we have a solution earlier, but we do not push it upstream
• If upstream goes a different direction, we do not adapt
• mvyskocil: technical problem should be we don't use a VCS for packages (and osc is not good VCS at all), so it's hard for packagers to understand why this patch was added and if it should be removed, or not. I considered something like Fedora CVS should be useful.
• mvancura: partially related to the problem of SUSE specific configuration as this is the same principle

Tags: usability, process, documentation, long-term
Interested: mvyskocil, Petr Uzel, Milan Vančura,anicka

Features are not known, they are not documented, thus not used and integrated, ...

• mvyskocil: we should inspire from Fedora and their Release Goals for every part of openSUSE. The current feature lists is just a big mess. So when we have a nice openfate, why we cannot have something useful as Fedora have?
  • tschmidt: every developer should help to have his features open for openfate. We could easily generate a list like fedora by tagging the important features with "11.2_main_feature" for example.

• features are not fully integrated (reaching 100% of their potential value)
  • Apport is excellent example. It can improve quality of bugreports, help with duplicities and make reporting easier. It is in repository, but is not used.
• There might be a central documentation point documenting all features that can be used to integrate: Desktop files, MIME types, firewall rules, HAL rules, udev rules, automatic mounting, Zeroconf,...

Tags: documentation, long-term, process
Interested: mvyskocil, Stanislav Brabec, Thomas Schmidt

Feature planning is done in very narrow view

• Broader context is typically lacking
• IMO this is the original cause of the "golden cage" problem - nadvornik
• Desktop features are enabled by default, but are not supported/tested/usable outside KDE/GNOME (for example the lack of commandline interface for networkmanager)
• mvancura: related also to "Goals of the project is missing" and "Missing supported scenarios"

Tags:
Interested: Vladimir Nadvornik, Milan Vančura, matejcik

Distribution designed by principle of 'golden cage'

• Works nicely if you are inside, breaking out of the cage is dangerous/not supported/broken
• Missing standard configuration files
• Automatically changing of configuration files
• Configuration files "hold" by an application (e.g. xorg.conf)
• Hard to find which is the right configuration file to change
• It is not limited to configuration files. Bug 298969 is an example where every user who wants to choose his applications is outside the cage.
• mvancura: too strict dependences: (example with SLES, not openSUSE:) I remember the Error message "The dependency of Product SLES broken, choose "uninstall SLES or revert your action" after selecting an alternative SW of some kind (I'm sorry, I don't remember details but it was something like choosing another e-mail client than the default one)
• mvancura: a relation to "Missing supported scenarios": there can be configuration sets prepared to some supported tasks but it must be easy to uninstall them AND still get the working system (without the special functionality set by the configuration addon). The prepared configuration mustn't block a chance to select/rewrite another one.

Tags:
Interested: Vladimir Nadvornik, Milan Vančura, anicka

Distribution is hacker-unfriendly

When a user slowly moves from a newbie to experienced one, he will typically leave for a different distro as adapting the system tends to be tiresome (small glitches all the way).
mvancura: I think this is a meta point with dependencies to many other ones (golden cage, complicated configuration files etc.). Some problems are described below:

• the amount of re-generated conffiles (after the installation) is too high and/or
• the way how some application (YaST module, SAX...) holds the conffile is too hard allowing no or near to no manual changes
• the way how (and if) the conffile may be edited isn't documented. Man pages (as an example) refer to general upstream version of the conffile and nothing about SUSE specific problems is there.
• the difference from upstream should be as small as possible
• "mess in the available packages"
• automatic changes in system (like startup,shutdown or configuration change of system services) aren't logged properly
• It would be nice to have at least the possibility to mark some config file like "I have edited it manually, I am sure I know what I want and I do not want to have it destroyed" in some way that any configs-modifying tool respects.
• When you want to see messages at the console during the boot, there is no way to find out how - you must guess that you should press Escape. (Actually, it is a more general problem: There are lots of places in our UI when you must just guess something. Have you ever noticed that many people do not know about possibility of choosing their packages during installation by clicking on the title of the paragraph in the installer? BTW, how did you find it out for the first time? Is not some button more proper solution?)
• From our default GNOME desktop, it is quite difficult even to run any terminal emulator.
• There is a tracker bug that collects known bug reports regarding this problem: https://bugzilla.novell.com/show_bug.cgi?id=481450

Tags: long-term, hard
Interested: Milan Vančura, Michal Čihař, anicka, jdluhos

Lack of polish, focus on details

Overall quality is rather high and most things "just work" out-of-the-box, but there are a lot of minor nuisances when you dive into details.
On the one hand, this is a general problem of the Linux desktop software. On the other hand, problem of openSUSE is that we don't do much to mitigate those little things (in some cases even create them, e.g. by setting up defaults in some way) and they add up very quickly.

Tags: long-term, usability, process
Interested: matejcik , anicka

Using GUI other than KDE and GNOME means user is on its own

• Maybe I'm wrong but flashdrives and cdroms are ussually mounted by some Gnome/KDE daemon via some HAL magic, so without KDE/Gnome user have to mount them manually?
• mvancura: I think this is an example of the next point "System too complex"
  • MasterPatricko: To a certain extent users (of all distros) have to accept that a majority of Linux user-oriented application development is based on either Qt/KDE or GTK/Gnome, simply because it saves so much duplication of effort by the developers. Remember that you can run most of those apps without running the whole DE. Although I do agree that specifically command-line only users could get far more tools available to them from openSUSE; that would go a long way to improving openSUSE's reputation as a server distro.

Tags: long-term, usability
Interested: Michal Hrusecky

System too complex (even in critical situations no easy way out)

• You need a network for some tasks
• Large stack of dependencies to fix problems
• mvancura: the previous point (Using GUI other than KDE and GNOME means user is on its own) the example of this more general point
• mvancura: I'm not in Packager team but it seems (from my POV) that it is because of a lack of a principle similar to Debian package priorities

Tags:
Interested: Milan Vančura, anicka

Not robust enough

• Failure scenarios are typically not covered, tested, defined
• At least, we have a YaST System Repair tool
• mvancura: this is a consequence of several points, including too big difference to upstream, too complicated configuration etc. Trying to solve this point with another application or YaST module is an equivalent of adding yet more complexity which should be avoided.

Tags:
Interested: Milan Vančura, anicka

Factory not usable most of the time

• the developers should try to use Factory for routine work when possible
  • bugs will be found much faster, everyone will do their best to keep Factory working
  • as developers are hackers, this will automatically make the distro more hacker-friendly
• could it be possible to guard against the most serious breaks automatically?
  • what about an early warning system that tries to at least run some apps and shows a big warning when the Factory is in unusable state?
• mvancura: Debian uses a special state of the package called "experimental". Those package versions aren't distributed as any Debian release and this stage exists only for getting *unstable* release more usable (and so "testable")
• it would help if also proprietary drivers for ATI and NVIDIA were available for Factory. It isn't problem to deal with it, but why bother?

Tags: long-term
Interested: Vít Pelčák, matejcik, jdluhos

All openSUSE web sites require log in

• mvyskocil: openID and no iChain should helps a little, but there are still many areas (well, it's only one called OBS ;-)), when we are too much closed. Other distributions are really opened:
  • Fedora CVS expose all Fedora packages with full history and for anonymous users
  • koji build info you have a full access to building informations from koji system and some of them are not available for OBS users at all.
  • Debian changelog browsing Debian offers a changelog browsing (they don't use a centralized VCS) without registration.
  • lintian reports or you can see a lintian issues for every package.
  • Debian build log Debian also offers an access to a build log of package.

Tags: community, hard, long-term
Interested: mvyskocil, Michal Čihař

No answer to 'restricted driver applet' from Ubuntu

• mvyskocil: Fedora contains some 'after installation wizard', or a Codec Buddy. We should also write our own as Yast module.
  • vpelcak: We could also try to create something like app-install in Debian/Ubuntu. While in package manager you select packages to install, in app-install you are selecting software. Simply, you see sections like "Multimedia", "Programming" ... and in each section you have programs with description (screenshot wouldn't hurt, too) where you can decide what to install (and also programs are marked by 0-5 stars according usage among people). So, it would be very friendly to users who would be otherwise confused.
• mvyskocil: this should be related to 'Multimedia support is lacking'

Tags: easy
Interested: mvyskocil, Petr Uzel

X drivers are flaky, not ready in time for release (ATI & nVidia)

• the SaX tool severely needs update+fixes+enhancements; it is excellent for simple scenarios, but almost certainly fails in more complex cases
  • support for multihead configs grows in importance with proliferation of laptops (many users have the laptop + extra monitor)
  • the xorg.conf file produced by SaX is overcomplicated and many parts are obsolete; a simpler file would work better with modern X.org servers
  • customization of xorg.conf is unsupported as SaX discards changes made to it.
• drivers themselves often fail miserably in (slightly) more complicated scenarios
  • it is a true challenge to make X.org work with more than two monitors
  • it is not that uncommon to have two gfx cards in a computer (large workstations, laptops with powersave/performance graphics option); currently this is a recipe for problems
  • X.org drivers are by far the most frequent cause of total freezes and crashes; bugs that cause this should be hunted mercilessly
• This link can be used to see a list of pending X.org-related bugs for the next openSUSE release.

Tags: hard
Interested: jdluhos

Missing single starting point for configuration of both desktop and system

• Current set of multiple control centers is confusing
• Beginer users sometime don't understand why are in X windows KDE od GNOME system duplicity setting for same thinks. For example in YaST we have setting for Video card and Monitors (Sax2) and in KDE4 is system setting is similar setting.
• Idea create link from KDE4 system setting to Yast, then beginer users will know there are some other options for Hardware/Software. They are looking for the Central setting form one other OS (- all options/setting in one place. )

Tags: easy
Interested:Martin Caj

Way we do packaging is ineffective

The currently used RPM and rpmbuild do not fit packagers needs anymore. Rpmbuild design forces packagers to spend their time in a mechanical modification of spec files and fixing problems in hundreds of instances. RPM has a lot of design problems, which were not targetted in past years. We spent thounsands of hours by inventing work-arounds.

Possible solutions:

• Invest effort to RPM development to fit our needs.
• Think about replacement of rpmbuild by a modern tool.
• Throw away rpm altogether and design package management from a new. Either there will be many hacks needed, or inner redesign of rpm will be so extensive, that it will not be compatible with old rpm anyway.
  • Would it be too revolutionary to move to deb? It has features RPM lacks and needs, so it would save lot of work.
    • And what about completely forking Debian codebase - Unstable branch?

Tags: hard, long-term
Interested: Michal Hrusecky, Pavol Rusnak, mvyskocil, Petr Uzel, Tomas Cech, anicka, Stanislav Brabec, Petr Gajdoš

Init system too complex, full of hacks

• Cleanup of current init system should shorten boot times, significantly. See also Boot time speedup project.
• Significant speed up can be also gained by usage of init-ng project.
  • Works quite well and boot times were really short compared to old init. Even faster than upstart.
  • Unfortunately, it is incompatible with old init.
• Other option can be openrc

Tags: hard, long-term, usability
Interested: Michal Hrusecky, Petr Uzel, anicka, Hans Petter Jansson

NetworkManager seen as problematic

• does not always work
• does not support IPv6
• there aren't logs for view, only way how to check what is happening, is check /var/log/messages, but you have to be root/sudo. For example Kinernet has simple log on two click
• Modem CDMA via network manager doesn't work
• Does anybody know how the NetworkManager works "inside" ? And why is so bad ?
• This is a typical example of feature planned in a narrow view. Network manager is a great tool for SLED users (it would be even better if it worked without crashes), but it's feature set is insufficient for powerusers which we want to attract with openSUSE. The problems are either ignored or solved at the very late stage, with ugly workarounds, like here.
• Maybe the best way, how to fix the NetworkManaget will be support other network managers for example the wicd looks nice, more info on web : wicd
• When you know it is broken, you still cannot avoid it once and forever: Even if you check that you do not want to use it during installation, it is still enabled in the default desktop.
• MasterPatricko: While NetworkManager is far from perfect life before NetworkManager was even worse; connecting to, for example, WPA WiFi was nearly impossible for the basic user. Now it works for 80% of the users by default. I do agree it should be easier to turn off for the users who know what they are doing and know it doesn't work for them. It has also been under heavy development and is IMO now reaching stability - though I can understand the frustration of SLE users who are stuck with old buggy versions.
• ang-cz: 80% isn't enough. (I have doubts about this number) For example we are using WPA enterprise with specific encryption end every time when I set this the NetworkManeger reset this encryption to none in Phase 2 part. For the normal user or beginner is fix this almost impossible.

Tags: long-term, usability
Interested: Martin Caj

Multimedia support is lacking

• ease of use
• explanations why it is so, ...

• potential risk of breakage of patent law - risky packages aren't installed by default
  • idea - what about usage of timezone selection to decide whether or not to install restricted packages automatically?
  • idea2 - I described it in "No answer to 'restricted driver applet' from Ubuntu"

• puzel: IMHO it is not trivial even for an experienced openSUSE user to properly setup multimedia support (codecs, dvd support, uncrippled xine libraries, ...).
  • it is a shame when I install openSUSE to someone, tell him it is easy to use, he comes after two days with it-cant-play-whatever complaints and I have to spend an hour or so in root terminal fixing it
  • I think that multimedia/restricted formats support is one of the first things one usually does after new installation
• mvyskocil: should be related to 'No answer to 'restricted driver applet' from Ubuntu'
• MasterPatricko: Packman provides a great service in this regard; it has even been distilled into a one-click install (see [1]]. Main problem is how does a completely new user find out about this.

Tags: easy
Interested: Petr Uzel, mvyskocil, Michal Hrusecky

Sync with mobile devices problematic/non-existent

• There currently exists several partial solutions (OpenSync, Gnome Conduit, ...), but none of them is finished and easy to setup.

• Idea: pick up one of solution (for example Opensync), finish the details fix bugs and create easy wizard for it.

• OpenSync is too low level, things like KitchenSync or Gnome Condiut are the right ones for end user.
  • mhrusecky: On the other hand these two are more dependent on specific GUI so we would need to polish two different tools (one for KDE and one for Gnome) and what about users who are using something else?
  • MasterPatricko: OpenSync is meant to make many of these problems easier, many projects now use it. OpenSync is under heavy development atm; the version included in SuSE releases is very old as we await the big new 0.40 release. As for frontends, other tools like msynctool (command-line) exist but most need some polish. Do remember KitchenSync and Gnome conduit can be run without the full DEs behind them. So yes it is a problem, but it is being worked on and is by no-means openSUSE specific.

Tags: hard, long-term, usability
Interested: Michal Hrusecky, Martin Caj, Michal Čihař

YaST software management UI for Qt and Gtk inconsistent and sometimes hard to use

• Same with ncurses UI
• mvyskocil: The software install is an example: Qt and Gtk version are two different products!
• If user changes desktop, he is lost in package manager, because something completely different shows up.
• We have wonderful instalation. Unfortunately, from time to time, unmatching and ugly yast dialog windows are shown.

Tags: usability
Interested: Michal Čihař, anicka

Poor state of Java applications

We have only one maintainer (Michal Vyskocil) for all Java (java-sun,java-ibm, java-openjdk, java-icedtea) and all Java-related packages (jPackage, Eclipse, ...). Because Java updates happen quite often (and have to be done for lots of vendor-platform combinations), other Java applications do not receive enough care.

Tags:
Interested:

Closed development process

• Non-transparent decision process, ...
• mvyskocil: I described this issue in 'Small community' and 'All openSUSE web sites require log in' sections. There are two main problems: we still have some internal tools (abuild, pdb, ...) not available for community and closed internal decisions (example should be a drop of RealPlayer without announce towards community). And also our open system (OBS) is not opened as much as possible and other distributions beats us.

Tags: community, process, long-term, hard
Interested: mvyskocil, anicka

sysconfig layer makes configuration non-transparent, too complex

• User has to learn new syntax, where can he change what he wants - too much different from upstream.
• Prevents user from configuration in a way he was used to in other distibutions/UNIXes.
• Maintaining it takes menpower from elsewhere as applications have to be modified against upstream to use it.
• Adds too much complexity which adds to possibility of bugs
• Some applications has sysconfig and it's own configuration
  • It is difficult to find out where to set particular feature
  • example MySQL bnc#465359
  • mvyskocil: another example is tomcat6. We use a version adopted from jpackage.org project, but number of sysconfig issues are still relative big. It's unclear when use sysconfig and when tomcat's own configuration.
• Golden Cage

Tags: easy, long-term, usability
Interested: Michal Hrusecky, mvyskocil, Petr Uzel, Milan Vančura, anicka

SuSEconfig makes configuration non-transparent, too much own intelligence

• SuSEconfig replaces missing RPM features. Without RPM change, there is no way to get it rid.
• Some features of SuSEconfig should be easily disable-able (e. g. MIME type association).
• mvancura: SuSEconfig must follow same rules as the rest of the system (should do - it doesn't actually do so), for example it mustn't change anything in /etc automatically while overwriting manual changes

Tags:
Interested: Milan Vančura

No configuration and package management rollback

Sometimes people want to try something new and experiment a little bit. They install new packages with a lot of dependencies or tries to change some configuration file manually. If they don't succeed it is hard to get back default configuration or get rid of all these unneeded dependencies

• MasterPatricko: This has been a regular feature request for a long time; in fact zypp now keeps history logs of package installations. But there is a fundamental problem where currently packages are installed one-by-one via rpm; to properly implement package management rollback like it should be we need to switch to a transaction-based system so that blocks of related packages can be rolled-back in one operation without causing dependency trouble or orphaned packages.

Tags: usability
Interested: Michal Hrusecky

In Progress

The issues that are tracked and hopefully planned to be worked on.

Mess in the available packages

• It's not clear which ones to install, BuildService adds another level of mess - which one to use, ..., missing simple packaging policy, how to find what user is looking for?
• Stricter rules might be useful
• No way to find out why a patch is included in a package
• Not clear definition of contrib repository (should user add kde(4):community or contrib repo to install kde(4) apps - which are not included in main repo ?)
• mvancura: a set of rpmlint tests fully corresponding to the packaging policy document must exist, be applied to both internally maintained packages and packages in contrib repository and only packages passing 100% tests can be a part of the distribution or contrib repository.
• mvancura: software.opensuse.org/search should distinguish clearly between contrib/repo and the rest (home projects). Showing home projects after setting "show me experimental packages" trigger only.
• mvancura: BuildService should be accessible anonymously for getting the software (no building)

Feature:
#305589: Checkbox "include user home projects in search"
#305591: Define purpose for each project
#305592: Warn on creating of the package that already exists in BuildService
Tags: Process, Documentation, long-term, hard
Interested: Petr Uzel, Michal Hrusecky, Vladimir Nadvornik, mvyskocil, Milan Vančura, Michal Čihař, anicka, Lukas Ocilka

No distribution upgrade in a running system

It's one of the most important features planned for openSUSE 11.2 However, we still don't have an easy and reliable solution.

• We have already started with YaST Wagon - an online migration tool

Feature: #305634: Debian-like dist-upgrade live system full version upgrade.
Tags: hard, openfate, usability
Interested: Lukas Ocilka, Milan Vančura, anicka

Usability of key management in software management

• When adding repository, (eg. using one click install) user is asked to confirm that he trusts several keys.
• With so many questions and no way to verify keys, this leads to no security.

Feature: #300754: Key Management for YAST / Zypper / Updaters
Tags: usability
Interested: Michal Čihař

Single starting point for documentation

• E.g. every command should have a manual page - Missing manpages
• jdluhos: can I propose using my little documentation project? (I know, it's very incomplete at the time, but this would change if more authors join)
• mvancura: "Each program, utility, and function should have an associated manual page included in the same package. It is suggested that all configuration files also have a manual page included as well. Manual pages for protocols and other auxiliary things are optional." - a citation of Debian Policy

Feature: #305336: Ship man page for every executable
Tags: documentation, long-term, easy
Interested: Jdluhos, mvyskocil, Petr Uzel, Milan Vančura, Michal Čihař

We don't know which packages users really use/have installed

• ranking, reporting from installation (ala Debian)
• some popcon's alternative (or reuse) should be great
• Packages usage statistics could be integrated into Software Portal and to YaST
• comparing relative results for individual packages between openSUSE and Debian can give us a valuable information about the community structure (how many users use development tools etc.)
• See also discussion on opensuse-project mailing-list User installation choices/settings

Feature: #305877: Popularity contest
Implementation: http://stick.gk2.sk/blog/2009/03/popcorn-popularity-contest-for-rpm/
Tags: community, usability, easy
Interested: mvyskocil, Vladimir Nadvornik, anicka, Pavol Rusnak

All openSUSE web sites require log in

• mvyskocil: openID and no iChain should helps a little, but there are still many areas (well, it's only one called OBS ;-)), when we are too much closed. Other distributions are really opened:
  • Fedora CVS expose all Fedora packages with full history and for anonymous users
  • koji build info you have a full access to building informations from koji system and some of them are not available for OBS users at all.
  • Debian changelog browsing Debian offers a changelog browsing (they don't use a centralized VCS) without registration.
  • lintian reports or you can see a lintian issues for every package.
  • Debian build log Debian also offers an access to a build log of package.

Feature: #306192: Make BuildService accessible for anonymous users
Tags: community, hard, long-term
Interested: mvyskocil, Michal Čihař

Done

The issues that are resolved now.

Drafts from e-mail thread (in Czech): here