February 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 302921] Testing openSUSE Feature Tracking
by fate_noreply＠suse.de 02 Feb '09

02 Feb '09

Feature changed by: Jan Engelhardt (jengelh) Feature #302921, revision 24 Title: Testing openSUSE Feature Tracking openSUSE-10.3: Done Priority Requester: Mandatory Requested by: Andreas Jaeger (a_jaeger) Partner organization: openSUSE.org Description: Just a test - should go to opensuse-features(a)opensuse.org Discussion: #1: Hendrik Vogelsang (hennevogel) (2007-10-30 13:00:36) blah blah blah #2: Hendrik Vogelsang (hennevogel) (2007-10-30 13:02:35) (reply to #1) blubb lubb lbuib #13: Hendrik Vogelsang (hennevogel) (2007-10-30 13:57:04) (reply to #1) dsdsdwsd #14: Hendrik Vogelsang (hennevogel) (2007-10-30 13:59:12) (reply to #13) wsdsdsds #15: Hendrik Vogelsang (hennevogel) (2007-10-30 14:01:10) (reply to #13) dsdsds #16: Hendrik Vogelsang (hennevogel) (2007-10-30 14:11:35) (reply to #13) ddsddds #3: Hendrik Vogelsang (hennevogel) (2007-10-30 13:12:39) this is working #4: Hendrik Vogelsang (hennevogel) (2007-10-30 13:16:03) (reply to #3) or bnot #10: Hendrik Vogelsang (hennevogel) (2007-10-30 13:48:53) (reply to #3) dwsdsdsd #5: Hendrik Vogelsang (hennevogel) (2007-10-30 13:27:44) swsasaas #6: Hendrik Vogelsang (hennevogel) (2007-10-30 13:33:36) sqsqasas #7: Hendrik Vogelsang (hennevogel) (2007-10-30 13:36:11) wdwdswd #8: Hendrik Vogelsang (hennevogel) (2007-10-30 13:38:00) dwsdsds #9: Hendrik Vogelsang (hennevogel) (2007-10-30 13:46:33) wswdds #11: Michael Loeffler (sprudel24) (2007-10-30 13:49:14) wjnd sd s�dlkj sid #12: Hendrik Vogelsang (hennevogel) (2007-10-30 13:52:27) (reply to #11) sasasas #17: Hendrik Vogelsang (hennevogel) (2007-10-30 14:48:56) (reply to #12) xdsdsds #18: Gerald Pfeifer (geraldpfeifer) (2007-11-02 21:51:25) Moving from openSUSE 10.3 to openSUSE 11.0. #19: Juergen Weigert (jnweiger) (2008-07-29 21:53:03) ping-pong. #20: Thomas Schmidt (digitaltomm) (2009-01-05 15:54:14) test... updated keeper + #21: Jan Engelhardt (jengelh) (2009-02-02 13:45:36) + My comment is supposed not to be saved! -- openSUSE Feature: https://features.opensuse.org/302921

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: Robert Davies (robopensuse) Feature #305634, revision 52 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. + #19: Robert Davies (robopensuse) (2009-02-02 13:45:04) (reply to #18) + There were a number of different forum poster's hitting it, just after + 11.1 released (I think due to zypper dup not YaST upgrade and therefore + unreported to BugZilla). It is not something I had, because I did fresh + installs. Interestingly though I have used Debian less, I have done + several dist-upgrade's, simply because it is expected to work well. So + it is a mistake to focus on specific tech issues alone. This problem is + also about expectations and user perceptions. Announcing "support" for + dist upgrade and appealing for test, so work rounds can be found, for + release notes at time matters to. -- openSUSE Feature: https://features.opensuse.org/305634

1 0

[openFATE 303678] New yast module - LIRC configuration
by fate_noreply＠suse.de 02 Feb '09

02 Feb '09

Feature changed by: Stanislav Visnovsky (visnov) Feature #303678, revision 19 Title: New yast module - LIRC configuration openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-06-24 15:31:30 reject reason: More urgent stuff to cover. Priority Requester: Desirable - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Stanislav Visnovsky <visnov(a)novell.com> + reject date: 2009-02-02 13:29:45 + reject reason: Out of scope. Postponing. Priority Requester: Desirable + openSUSE-11.3: New + Priority + Requester: Desirable Requested by: Ladislav Slezak (lslezak) Partner organization: openSUSE.org Description: Create a new Yast module for configuring IR receivers and remote controls. * irrecord support * ir-kbd-i2c, ir-kbd-gpio support as in tv module already * reading users' config to find out what buttons were defined (only if /home partition left from last installation) * support for lirc's options in /etc/sysconfig See bug https://bugzilla.novell.com/show_bug.cgi?id=381641 -- openSUSE Feature: https://features.opensuse.org/303678

1 0

[openFATE 305394] Move KDE software updates notifications to upstream infrastructure
by fate_noreply＠suse.de 02 Feb '09

02 Feb '09

Feature changed by: Stanislav Visnovsky (visnov) Feature #305394, revision 12 Title: Move KDE software updates notifications to upstream infrastructure openSUSE-11.2: Evaluation Priority Requester: Important + Projectmanager: Important Requested by: Duncan Mac-Vicar (dmacvicar) Partner organization: openSUSE.org Description: As kpackagekit matures, it may be the case that for 11.2 it is mature enough for replacing kupdateapplet. It already implements various aspects of kupdateapplet: * notifications (knotify) using a kded service (which takes care of refreshing too) * single update selection (kpackagekit gui) * uses a upstream client library for communication with PackageKit, which are better than our PackageKit communication code. Scope kpackagekit is meant here only to replace kupdateapplet. There is not relation with YaST here. Open Issues: * tray notification: may require implementing a plasma tray icon * SUSE specific code (smolt, registration, hardware search) * Requires some research how to introduce those extensions in kpackagekit, or move SUSE specific parts out, like another kded service. User experience Should stay the same Dependencies * PackageKit * libpackagekit-qt Contingency Plan In the case kpackagekit is not yet mature enough, the same resources invested now in kupdateapplet can be invested in improving kpackagekit. Otherwise, we can stay with kupdateapplet as a fallback. Relations: - kpackagekit author interview (url: http://polishlinux.org/kde/kpackagekit-interview/) - kpackagekit screenshot (url: http://www.packagekit.org/img/kpk-update.png) Test Case: * new patches should be notified by knotify * user should be able to see update availability * user should be able to see detailed update information, as well as selecting individual updates * user should get informed if the update repositories configuration has a problem * user should be informed of (available) drivers for plugged hardware Business case (Partner benefit): openSUSE.org: Right now software notifications are done using the kupdateapplet, which comes from the opensuse-updater code,(renamed in a non sucessful attept to upstream it). This applet come from a summer of code project, originally done as a zmd client, then evoluted to a zypper client, and now working as a PackageKit client. Sadly, during 10.3 cycle this applet got the feature to select updates individually and other small stuff which turned it into a very complicated piece of code, and started to became a package manager on its own. Later it became the favorite place to plug any kind of notifications, like registration needed, smolt participation, etc, and right now the code is much more complex that it should be (thus taking more maintenance and testing than it should require). This feature has the objective of cleaning up this situation to free resources in this area. With the progress of packagekit and recently, kpackagekit, this should be possible. kpackagekit already implements various of the needed aspects, and therefore it would mean getting rid of in house code for upstream code. Additionally, it would result in a much more consistant user experience as the tools would be similar across distributions. Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-23 14:24:20) Looks like Duncan is in favor of this. Stano? If you guys are comfortable with the change, I am all for it. But remember, priority #1 is dist-upgrade. -- openSUSE Feature: https://features.opensuse.org/305394

1 0

[openFATE 302119] Load package selector and libzypp only when needed
by fate_noreply＠suse.de 02 Feb '09

02 Feb '09

Feature changed by: Stanislav Visnovsky (visnov) Feature #302119, revision 32 Title: Load package selector and libzypp only when needed openSUSE-10.3: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2007-08-01 16:40:54 reject reason: Postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.0: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-04-28 13:42:30 reject reason: Did not make it, postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-09-12 14:13:58 reject reason: Postponing. Priority Requester: Desirable Projectmanager: Important - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Stanislav Visnovsky <visnov(a)novell.com> + reject date: 2009-02-02 13:15:32 + reject reason: Out of scope. Priority Requester: Desirable + openSUSE-11.3: New + Priority + Requester: Desirable Requested by: Stefan Hundhammer (sh-sh-sh) Partner organization: openSUSE.org Description: The YaST2 UI should load the code for the package selector and libzypp only when needed. Not all applications / YaST2 modules need package selection code, yet for all of them the respective code from the YaST2 UI and libzypp is loaded. Discussion: #1: Stefan Hundhammer (sh-sh-sh) (2007-04-13 18:13:44) In the YaST2 Qt the package management related code is now moved to a separate plugin that is loaded upon demand only if the calling YCP application actually requests a PackageSelector widget. This reduces the memory footprint from 20 MB VmRSS minimum (HelloWorld. ycp) to 18 MB minimum (PackageSelector-empty.ycp). #3: Katarina Machalkova (kmachalkova) (2007-04-16 14:41:35) Stano, do we want this for curses UI as well? If yes, than it's not 'done' ... #4: Stanislav Visnovsky (visnov) (2007-04-16 14:47:02) (reply to #3) Agreed. Reopening for ncurses and possibly gtk+. #5: Jiri Srain (jsrain) (2007-06-13 13:54:26) JP, both Qt and NCurses are done, but GTK is still missing. #6: Stefan Hundhammer (sh-sh-sh) (2007-06-13 15:08:58) Looks like yast2-pkg-bindings are also loaded unconditionally. It shouldn't be too hard to do that with "lazy initialization" like UI built-ins: Postpone loading the Y2Component until it's really needed. #7: Stanislav Visnovsky (visnov) (2007-06-19 15:01:54) (reply to #6) Jiri, if Pkg bindings problem is not addressed, it does not make sense to fix Gtk UI. #8: Jiri Srain (jsrain) (2007-07-18 13:59:50) (reply to #7) Sorry for missing this. Martin, please, solve this for the Pkg bindings. #11: Martin Vidner (mvidner) (2008-04-10 15:23:51) yast2-perl-bindings-2.16.6 no longer links to libzypp, which means libzypp will not be loaded at the very start of yast (perl still will be loaded, but that is relatively cheap). That helps in some cases, but mostly it only delays loading of libzypp, which occurs as soon as Pkg (or Package) is imported. Now I need to make Pkg lazy. #12: Martin Vidner (mvidner) (2008-04-21 15:32:09) I have it almost working, but got stopped by bug 381917 (https://bugzilla.novell.com/show_bug.cgi?id=381917) : problems with destructors of static objects #13: JP Rosevear (jproseve) (2008-07-21 13:59:18) (reply to #12) Martin, what's the status here? Will we need to do anything explicit in packagekit to get this functionality? #14: Stanislav Visnovsky (visnov) (2008-09-08 16:44:06) (reply to #13) There is nothing regarding packagekit for this feature. -- openSUSE Feature: https://features.opensuse.org/302119

1 0

[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