February 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 100048] MySQL Configuration
by fate_noreply＠suse.de 02 Feb '09

02 Feb '09

Feature changed by: Stanislav Visnovsky (visnov) Feature #100048, revision 27 Title: MySQL Configuration openSUSE-10.3: Rejected by Andreas Jaeger <aj(a)novell.com> reject date: 2007-07-16 19:10:56 reject reason: Too late for 10.3. Priority Requester: Desirable openSUSE-11.0: Rejected by Duncan Mac-Vicar <dmacvicar(a)novell.com> reject date: 2008-03-18 12:42:12 reject reason: We don't have the resources to finish this module. I will move it to http://en.opensuse.org/Summer_of_Code_2008#YaST_ideas Priority Requester: Desirable Projectmanager: Desirable openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-06-26 16:11:49 reject reason: Out of resources. Priority Requester: Desirable - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Stanislav Visnovsky <visnov(a)novell.com> + reject date: 2009-02-02 13:14:30 + reject reason: Out of scope. Priority Requester: Desirable Requested by: Lukas Ocilka (locilka) Partner organization: openSUSE.org Description: MySQL is used very often on servers. There should be management tool for databases, and database-users and for some mysql-variables (key_buffer, write_buffer and more). Discussion: #1: Lukas Ocilka (locilka) (2005-11-29 15:46:59) Novell to Offer MySQL Network * http://www.mysql.com/news-and-events/press-release/release_2005_28.html * Novell offers affordable database software and support services through 'MySQL Network' subscriptions #2: Gerald Pfeifer (geraldpfeifer) (2006-01-03 14:03:13) Holger, can you please qualify this from a PM perspective? (Not for CODE10, of course, but CODE11 or SL10.2/10.3, for example.) #5: Duncan Mac-Vicar (dmacvicar) (2008-03-18 12:41:18) We don't have the resources to finish this module. I will move it to http://en.opensuse.org/Summer_of_Code_2008#YaST_ideas -- openSUSE Feature: https://features.opensuse.org/100048

1 0

[openFATE 305268] Refactor bootloader UI
by fate_noreply＠suse.de 02 Feb '09

02 Feb '09

Feature changed by: Stanislav Visnovsky (visnov) Feature #305268, revision 4 Title: Refactor bootloader UI openSUSE-11.2: Evaluation Priority Requester: Mandatory + Projectmanager: Mandatory Requested by: Jiri Srain (jsrain) + Partner organization: openSUSE.org Description: In order to simplify maintenance, allow to fix some bugs and also use more flexibility of YaST UI, the user interface of the bootloader module should be rewritten to YCP instead of using generator with limited possibilities. Discussion: #2: Federico Lucifredi (flucifredi) (2009-01-26 20:45:53) prioritizing cleanup task as per plan. + #3: Stanislav Visnovsky (visnov) (2009-02-02 13:11:26) + Jiri, please, document the planned changes and provide a link for the + feature. -- openSUSE Feature: https://features.opensuse.org/305268

1 0

[openFATE 305622] Add support for lzop compression to GNU tar
by fate_noreply＠suse.de 02 Feb '09

02 Feb '09

Feature changed by: Matthias Eckermann (mge1512) Feature #305622, revision 11 Title: Add support for lzop compression to GNU tar openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Matthias Eckermann (mge1512) Partner organization: openSUSE.org Description: (iaW) update to tar 1.21 + Use Case: + 'tar' is one of the most important archiving tools for Linux and Unix- + like systems in general. Our version should be capable of interacting + with all other versions including the respective compression algorithms + and tools. Discussion: #1: Jan Engelhardt (jengelh) (2009-01-19 09:32:51) tar --use=lzop -cf foo.tar.lzop #2: roland kletzing (rkletzin) (2009-01-20 21:44:53) shouldn`t we first have lzop package being part of the distro/factory, before make standard tools using it? (also see https://bugzilla.novell.com/show_bug.cgi?id=461228) it`s on the wishlist for a long time now, glad to see that we have openFate now (since adding to the wishlist was as good as talking to a wall) -- openSUSE Feature: https://features.opensuse.org/305622

1 0

[openFATE 302963] Rating support for FATE
by fate_noreply＠suse.de 02 Feb '09

02 Feb '09

Feature changed by: Michael Loeffler (sprudel24) Feature #302963, revision 19 Title: Rating support for FATE openFATE: Evaluation Priority Requester: Important Requested by: Duncan Mac-Vicar (dmacvicar) Partner organization: openSUSE.org Description: FATE is becoming a huge database of useless information. Most of this come to the fact that there is only syntantic checking but not social checking. Usecase: Searching and navigating produces lot of: * Duplicate features * Incomplete features (no use cases, examples) * Vague features (a.k.a "#xxxxx YaST should be improved" ) * copy and paste features Features should support rating in the slashdot way (Insightful, Interesting, Informative, Troll, Funny) and rating from 1 to 5. The rating could be used so the same people using FATE could score down low- quality features than only make the process of information flow more difficult. Score threshold could be set by people so only high quality, well specified features are shown. It is important that searching could be done using this ratings. It should be possible to generate rankings over this ratings. Current status FATE does not offer anything to filter low quality features User Experience Query dialog would gain an option for searching. Feature editor would gain a rating dialog where different people would express their rating. Search would be over an average or agregation of this scores. Scores should be saved per rater. Contingency Plan No contingency plan at the software level. At the process level, add comments to every feature lacking business case, detailed description, real benefits, and more important, scope. Documentation Impact: Only needs to be mentioned in the handbook. Test Case: * rate a feature in one or two dimensions (score and category) * search for features >= or <= certain rating Business case (Partner benefit): openSUSE.org: Threshold for feature processing should save thousands of dollars in wasted time doing ping pong, needinfos for features with incomplete information. Even engineering could be optimized when features with no real business case dissapear by social tagging. Discussion: #1: Gerald Pfeifer (geraldpfeifer) (2008-04-02 01:26:51) Sounds like an interesting idea for openSUSE. I am looking forward towards considering this for some Phase 2 or so once openFATE (or whatever the name is going to be) is up and running. #3: Stephan Binner (beineri) (2009-01-17 16:03:07) (reply to #1) openFATE is now up and running. Can this request be made public to openSUSE.org partner? #2: Gerald Pfeifer (geraldpfeifer) (2008-11-14 18:05:55) Michl, for the openFATE work. (For SLE, I expect the PMs to take on much of this.) #4: Francis Giannaros (apokryphos) (2009-01-28 16:04:18) This would be great to see. For reference, see https://blueprints.launchpad.net/ubuntu with some good ideas. Also a tag cloud like the build service has might be nice. #5: Andre Duffeck (aduffeck) (2009-01-28 16:14:23) (reply to #4) We will release a new openFATE version by the end of the week with both voting and tagging support (including a cloud ;)) #7: Francis Giannaros (apokryphos) (2009-01-30 20:29:40) (reply to #5) Awesome! #6: Thomas Schmidt (digitaltomm) (2009-01-30 15:12:39) Rating features is available now in openfate with the three options -0 +. Searching for features with or above a certain score is not yet there. Do we need to integrate the voting and search by rating stuff in the FATE client or is this just a community feature? #8: Stephan Binner (beineri) (2009-01-31 11:46:14) (reply to #6) Can you please add a voting column to the browse/query result list and allow sorting by it? Atm you seem to be only able to view the top 5 voted requests (on the dashboard). + #10: Michael Loeffler (sprudel24) (2009-02-02 11:35:31) (reply to #8) + Yes, it would be useful to see the score already while brosing through + the features. + #9: Michael Loeffler (sprudel24) (2009-02-02 11:34:32) (reply to #6) + Voting is not necessary for the internal client. Internal features + should be more driven by use case and business case. For openFate the + public opinion is more important to know. But the voting score of + external features should be displayed internally. -- openSUSE Feature: https://features.opensuse.org/302963

1 0

[openFATE 305634] Debian-like dist-upgrade live system full version upgrade
by fate_noreply＠suse.de 02 Feb '09

02 Feb '09

Feature changed by: Thorsten Kukuk (kukuk) Feature #305634, revision 51 Title: Debian-like dist-upgrade live system full version upgrade openSUSE-11.2: Evaluation Priority Requester: Mandatory Info Provider: Robert Davies (robopensuse) Requested by: Federico Lucifredi (flucifredi) Partner organization: openSUSE.org Description: With the 11.2 cycle, we want to offer users the ability to perform a live system upgrade in the manner of Debian's dist-upgrade. For the purpose of this cycle, we want to support dist-upgrade from the previous version (11.1) only, as this is a sufficiently complicated problem as is. From the user's view, the difference is between being able to update the system incrementally within the given version or service pack running, to being ble to migrate with a system command ("zypper dup" or similar) to a higher version altogether. In the Debian experience, the set of base distributions is not necessarily limited, but it has been Ubuntu's practice to define what starting points other than "release n-1" are allowed (for instance, all LTS versions are purported to be able to "apt dist-upgrade" to the top of the line, although I have heard of problems trying to jump two years - 6.06->8.10 - in a fell swoop in this manner :-). In the openSUSE scope, we should aim to be able to "dup" between incremental versions, starting from 11.1 to 11.2, and later 11.x to 12.0. Business case (Partner benefit): openSUSE.org: With the introduction of the Zypper stack to SLE, we finally reached the state of a featureful (which YOU was not) and fast, reliable (which ZLM was not) update stack in the platform. For enterprise use, some tweaks are still desirable (changelogs, rollback, ...) which we are looking at, as well as improvements on the Enterprise management front, which we are working on with our SRM colleagues. The only really significant competitive feature we are missing at this point is the Debian/Ubuntu dist-upgrade functionality, which has a powerful psychological impact at the Enterprise level and a much more tangible impact at the small user / single user level: many with no IT department do use Ubuntu these days on the basis that "chasing" Fedora and openSUSE along the six-month upgrade cycle is too much for them, and feel they can save time on Ubuntu with the combination of dist- upgrade and the longer LTS cycle. The rationale for pursuing this is to revoke the special status of coolness this functionality gives Ubuntu, and to terminate the negative influence that may have on our SLE sales (from the expert's personal opinion, the preference then easily spills into purchasing). Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-07 20:42:15) This is the #1 feature in the systems management scope for 11.2 - I have no doubt it will be fun :-) #4: Klaus Kämpf (kwk) (2009-01-09 11:32:53) Passing to mls for technical evaluation (solver + autobuild) #5: Michael Schröder (mlschroe) (2009-01-09 12:48:10) Any hint on what features are currently missing? #6: Klaus Kämpf (kwk) (2009-01-09 13:30:57) (reply to #5) From the top of my head: How to handle * Library ABI changes (e.g. major gcc/g++ upgrades) ? * Core package changes (e.g. devs.rpm to udev) ? * Kernel changes (if application/deamons need a specific kernel abi, dbus comes into mind) ? * Failure handling (network breakdown, package update errors, ...) ? * Booting of the new kernel ? #7: Michael Schröder (mlschroe) (2009-01-09 14:45:09) (reply to #6) And debian does this in some way? #8: Robert Davies (robopensuse) (2009-01-17 12:43:42) (reply to #7) The distupgrade feature differs from changing source list and doing upgrade, so some utility process could be started. They may require some documented procedure to be followed, for "tough" changes. But ABI change, how long since ELF/glibc was introduced? C++ ABI ought not be relevant for upgrade process, they are "just" applications and libaries to be updated. Failure handling - you are told to back up your system first, it is "best effort" not guaranteed. The less you have installed the more likely it is to succeed. Debian offer choice of kernels, this may "punt" the problem to a user controlled install and select from GRUB menu. Debian have apt-cache possibility, to create central pool of packages, to decrease liklihood of network troubles, as well as huge number CD and DVD iso's. #9: Thorsten Kukuk (kukuk) (2009-01-17 15:24:35) (reply to #8) The glibc internal ABI changes frequently. Means, running applications will continue to use the old glibc with the old ABI, but installed are already the new plugins => running applications can crash. #12: Robert Davies (robopensuse) (2009-01-31 15:36:30) (reply to #9) But your upgrade tools are buggy if they are built to rely on "plugins". If you try to dist upgrade a live system within GUI, with all software running, and no breakage, you aim impossibly high. The point is, Debian have had very positive user comments for years about this feature, despite there being many caveats and no guarantee of success. #13: Robert Davies (robopensuse) (2009-01-31 15:42:55) (reply to #12) That wasn't clear. The upgrade tools are built so they won't suffer from changes. It is reasonable to ask user to not be running uncessary applications during a dist upgrade. #16: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:19:55) (reply to #12) Thorsten is talking about general applications. Not plugins. #10: Cristian Rodríguez (elvigia) (2009-01-20 03:36:38) (reply to #8) ABI is important during the upgrade process, I have seen applications crashing if you upgrade running a desktop enviroment, however we need to worry more about other stuff first IMHO. #11: Duncan Mac-Vicar (dmacvicar) (2009-01-29 16:51:48) I think the "Debian" part of the title is missleading if what we want is just to support dup officially. I would like to see a list from some "Debian expert" on how to Debian handles the issues Klaus described above. Appart of the network failure (included in another feature: commit) I ignore (and did not experience during my old Debian times) if Debian does anything special on dist- upgrade which give them the honour to name this feature "Debian like". Otherwise this feature should be closed as "done", (or just waiting for the commit refactoring). Federico, as you named the feature "Debian-like", It would be helpful to know, appart of the download-first feature, what are you missing from Debian so we can reach that point. #14: Robert Davies (robopensuse) (2009-01-31 15:54:26) (reply to #11) Technically you may be right, but that does not solve the perceived problem for end users who want a very well tested, and documented upgrade path. 11.1 shipped with release notes without solutions for problems folk hit (eg) PAM stuff). #15: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:22:12) (reply to #14) Exactly, but if we don't know what specific problems are we hitting during distupgrade the feature has no real work and specific problems can be tracked as bugs. FATE is not a place for "make this better" without concrete requirements or "make an unfalible distupgrade". If requester, prjmgr, or pm expects anything to be done in the area, we need at least: * A list of problems we hit during dist upgrade (I am aware of one specific, which is download-install sequence if network goes down) * The scope. As you mention, asking to close every application (or service) is not much to ask. Therefore the scope has to be set, because if the scope is "distupgrade and glbc upgrade while oracle process hospital monitoring equipment transactions" then this is a very expensive feature. #17: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:21:02) (reply to #14) btw, can you describe in technical detail the pam upgrade problem so we can document it? + #18: Thorsten Kukuk (kukuk) (2009-02-02 10:26:58) (reply to #17) + Yes, the PAM maintainers would like to know more details, too. -- openSUSE Feature: https://features.opensuse.org/305634

1 0

[openFATE 305634] Debian-like dist-upgrade live system full version upgrade
by fate_noreply＠suse.de 02 Feb '09

02 Feb '09

Feature changed by: Duncan Mac-Vicar (dmacvicar) Feature #305634, revision 50 Title: Debian-like dist-upgrade live system full version upgrade openSUSE-11.2: Evaluation Priority Requester: Mandatory + Info Provider: Robert Davies (robopensuse) Requested by: Federico Lucifredi (flucifredi) Partner organization: openSUSE.org Description: With the 11.2 cycle, we want to offer users the ability to perform a live system upgrade in the manner of Debian's dist-upgrade. For the purpose of this cycle, we want to support dist-upgrade from the previous version (11.1) only, as this is a sufficiently complicated problem as is. From the user's view, the difference is between being able to update the system incrementally within the given version or service pack running, to being ble to migrate with a system command ("zypper dup" or similar) to a higher version altogether. In the Debian experience, the set of base distributions is not necessarily limited, but it has been Ubuntu's practice to define what starting points other than "release n-1" are allowed (for instance, all LTS versions are purported to be able to "apt dist-upgrade" to the top of the line, although I have heard of problems trying to jump two years - 6.06->8.10 - in a fell swoop in this manner :-). In the openSUSE scope, we should aim to be able to "dup" between incremental versions, starting from 11.1 to 11.2, and later 11.x to 12.0. Business case (Partner benefit): openSUSE.org: With the introduction of the Zypper stack to SLE, we finally reached the state of a featureful (which YOU was not) and fast, reliable (which ZLM was not) update stack in the platform. For enterprise use, some tweaks are still desirable (changelogs, rollback, ...) which we are looking at, as well as improvements on the Enterprise management front, which we are working on with our SRM colleagues. The only really significant competitive feature we are missing at this point is the Debian/Ubuntu dist-upgrade functionality, which has a powerful psychological impact at the Enterprise level and a much more tangible impact at the small user / single user level: many with no IT department do use Ubuntu these days on the basis that "chasing" Fedora and openSUSE along the six-month upgrade cycle is too much for them, and feel they can save time on Ubuntu with the combination of dist- upgrade and the longer LTS cycle. The rationale for pursuing this is to revoke the special status of coolness this functionality gives Ubuntu, and to terminate the negative influence that may have on our SLE sales (from the expert's personal opinion, the preference then easily spills into purchasing). Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-07 20:42:15) This is the #1 feature in the systems management scope for 11.2 - I have no doubt it will be fun :-) #4: Klaus Kämpf (kwk) (2009-01-09 11:32:53) Passing to mls for technical evaluation (solver + autobuild) #5: Michael Schröder (mlschroe) (2009-01-09 12:48:10) Any hint on what features are currently missing? #6: Klaus Kämpf (kwk) (2009-01-09 13:30:57) (reply to #5) From the top of my head: How to handle * Library ABI changes (e.g. major gcc/g++ upgrades) ? * Core package changes (e.g. devs.rpm to udev) ? * Kernel changes (if application/deamons need a specific kernel abi, dbus comes into mind) ? * Failure handling (network breakdown, package update errors, ...) ? * Booting of the new kernel ? #7: Michael Schröder (mlschroe) (2009-01-09 14:45:09) (reply to #6) And debian does this in some way? #8: Robert Davies (robopensuse) (2009-01-17 12:43:42) (reply to #7) The distupgrade feature differs from changing source list and doing upgrade, so some utility process could be started. They may require some documented procedure to be followed, for "tough" changes. But ABI change, how long since ELF/glibc was introduced? C++ ABI ought not be relevant for upgrade process, they are "just" applications and libaries to be updated. Failure handling - you are told to back up your system first, it is "best effort" not guaranteed. The less you have installed the more likely it is to succeed. Debian offer choice of kernels, this may "punt" the problem to a user controlled install and select from GRUB menu. Debian have apt-cache possibility, to create central pool of packages, to decrease liklihood of network troubles, as well as huge number CD and DVD iso's. #9: Thorsten Kukuk (kukuk) (2009-01-17 15:24:35) (reply to #8) The glibc internal ABI changes frequently. Means, running applications will continue to use the old glibc with the old ABI, but installed are already the new plugins => running applications can crash. #12: Robert Davies (robopensuse) (2009-01-31 15:36:30) (reply to #9) But your upgrade tools are buggy if they are built to rely on "plugins". If you try to dist upgrade a live system within GUI, with all software running, and no breakage, you aim impossibly high. The point is, Debian have had very positive user comments for years about this feature, despite there being many caveats and no guarantee of success. #13: Robert Davies (robopensuse) (2009-01-31 15:42:55) (reply to #12) That wasn't clear. The upgrade tools are built so they won't suffer from changes. It is reasonable to ask user to not be running uncessary applications during a dist upgrade. + #16: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:19:55) (reply to #12) + Thorsten is talking about general applications. Not plugins. #10: Cristian Rodríguez (elvigia) (2009-01-20 03:36:38) (reply to #8) ABI is important during the upgrade process, I have seen applications crashing if you upgrade running a desktop enviroment, however we need to worry more about other stuff first IMHO. #11: Duncan Mac-Vicar (dmacvicar) (2009-01-29 16:51:48) I think the "Debian" part of the title is missleading if what we want is just to support dup officially. I would like to see a list from some "Debian expert" on how to Debian handles the issues Klaus described above. Appart of the network failure (included in another feature: commit) I ignore (and did not experience during my old Debian times) if Debian does anything special on dist- upgrade which give them the honour to name this feature "Debian like". Otherwise this feature should be closed as "done", (or just waiting for the commit refactoring). Federico, as you named the feature "Debian-like", It would be helpful to know, appart of the download-first feature, what are you missing from Debian so we can reach that point. #14: Robert Davies (robopensuse) (2009-01-31 15:54:26) (reply to #11) Technically you may be right, but that does not solve the perceived problem for end users who want a very well tested, and documented upgrade path. 11.1 shipped with release notes without solutions for problems folk hit (eg) PAM stuff). + #15: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:22:12) (reply to #14) + Exactly, but if we don't know what specific problems are we hitting + during distupgrade the feature has no real work and specific problems + can be tracked as bugs. + FATE is not a place for "make this better" without concrete + requirements or "make an unfalible distupgrade". + If requester, prjmgr, or pm expects anything to be done in the area, we + need at least: + * A list of problems we hit during dist upgrade (I am aware of one + specific, which is download-install sequence if network goes down) + * The scope. As you mention, asking to close every application (or + service) is not much to ask. Therefore the scope has to be set, because + if the scope is "distupgrade and glbc upgrade while oracle process + hospital monitoring equipment transactions" then this is a very + expensive feature. + #17: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:21:02) (reply to #14) + btw, can you describe in technical detail the pam upgrade problem so we + can document it? -- openSUSE Feature: https://features.opensuse.org/305634

1 0

[openFATE 305296] Easy Way to Disable Beagle Completely During Installation
by fate_noreply＠suse.de 01 Feb '09

01 Feb '09

Feature changed by: Thomas Beimel (RheydterGekko) Feature #305296, revision 16 Title: Easy Way to Disable Beagle Completely During Installation openSUSE-11.2: Evaluation Priority Requester: Important Requested by: JP Rosevear (jproseve) Partner organization: openSUSE.org Description: We need to either have beagle off by default and allow a user to enable it the first time they search or provide an install option to turn it off. Relations: - Better Beagle Acceptance (feature/id: 303367) - Easy way to disable beagle completely during install (novell/bugzilla/id: 282678) https://bugzilla.novell.com/show_bug.cgi?id=282678 Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:52:46) I prefer to start with disabled, offer option to run at first search. We are proliferating checkboxes in the installer too much. #2: Kevin Dupuy (kdupuy9) (2009-01-29 23:40:17) I prefer a more sane option than disabling it by default... instead, allow the user to go in and uninstall it from the installation software screen, just as they would any other app (perhaps make 'Desktop Search' pattern, installed by default?) We just need to insure that uninstalling Beagle doesn't throw up any dependency errors. #3: Eric Springer (erikina) (2009-01-30 00:16:23) Every single openSUSE install I've done has resulted in beagle being removed. It slows down the computer, and the firefox extension throws lots of errors. I'm quite happy with how easy it is to remove, and I can see why it's useful -- but unless its seriously improved, I think it should be removed (by default) #4: Jan Engelhardt (jengelh) (2009-01-30 15:22:34) Maybe pulseaudio should be too, for slightly similar reasons. :) #5: Rastislav Krupansky (ra100) (2009-01-31 13:10:36) (reply to #4) exactly right ;-) + #6: Thomas Beimel (rheydtergekko) (2009-02-01 16:22:09) + Yes this would be an perfect option during installation. Especially + because I prefer to have a new installation that consumes as less + resources as possible. I do not need indexing service and I think many + others as well. -- openSUSE Feature: https://features.opensuse.org/305296

1 0