November 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 305883] Install and boot support for MDRAID External Metadata (ISW)
by fate_noreply＠suse.de 25 Nov '09

25 Nov '09

Feature changed by: Arvin Schnell (aschnell) Feature #305883, revision 27 Title: Install and boot support for MDRAID External Metadata (ISW) openSUSE-11.2: Rejected by Stephan Kulow (coolo) reject date: 2009-09-10 10:23:06 reject reason: too late for 11.2 Priority Requester: Important Requested by: Marc Ruehrschneck (macrue) Partner organization: openSUSE.org Description: Support for MDRAID External Metadata ISW for raid 0, 1, 10 and 5, 6 (??). User should have a choice between DMRAID and MDRAID or have no DMRAID support. This feature request has three aspects: 1) Detection of RAID arrays and platform capabilities Currently SLES can detect raid arrays but it does not confirm whether raid is enabled in the platform BIOS. If raid support has been disabled in the BIOS then arrays should not be presented as candidates for installation Currently "mdadm --detail-platform -e imsm" could be used for this detection as it returns true when the platform has Intel(R) Matrix Storage Manager support enabled. 2) Creating an initrd with support for assembling ISW raid arrays This has dependencies on how FR#781 is resolved (mdp versus kpartx) and needs support for handling the metadata dirty bit FR#782. At a minimum it involves adding something akin to the following commands to the initrd init script: ... mdadm -Asc mdadm.conf mount /dev/md/Volume0p1 /sysroot mdmon --switch-root /sysroot /dev/md/imsm0 ... 3) Installing the bootloader on a RAID device Fortunately the version of grub in SLES11-beta6 seems to already understand/expect partitionable md arrays as the following grub commands: root (hd0,0) setup (hd0) ...ends in a failure to access /dev/md/Volume0p1. So this may add weight to the mdp case for FR#781. Adding a link to the kpartx partition, that SLES11 currently creates, allows this to grub installation to complete successfully. However, this required hand editing of /boot/grub/device.map so the final solution will probably require a utility to dump the grub device to raid device mapping, or the restriction that the raid device must be grub device (hd0). Business case (Partner benefit): openSUSE.org: Enable feature parity with the Windows IMSM stack for Linux customers Discussion: #6: Matthias Eckermann (mge1512) (2009-09-07 13:08:16) As long as Intel is helping us, we should not reject this. #11: Arvin Schnell (aschnell) (2009-11-10 11:55:12) I have now merged the code from Intel to the YaST SLE11 SP1 code. Unfortunately there are still some open issues discovered lately during development, e.g. modification to mdadm.conf and support for udev ids. Also the code has never been tested during installation so expect bug reports. #12: Thorsten Kukuk (kukuk) (2009-11-25 11:18:35) (reply to #11) Does this mean we can clos this as done and handle the rest via bugzilla? If yes, please close. + #13: Arvin Schnell (aschnell) (2009-11-25 11:23:55) (reply to #12) + Ok, closing. -- openSUSE Feature: https://features.opensuse.org/305883

1 0

[openFATE 305883] Install and boot support for MDRAID External Metadata (ISW)
by fate_noreply＠suse.de 25 Nov '09

25 Nov '09

Feature changed by: Thorsten Kukuk (kukuk) Feature #305883, revision 26 Title: Install and boot support for MDRAID External Metadata (ISW) openSUSE-11.2: Rejected by Stephan Kulow (coolo) reject date: 2009-09-10 10:23:06 reject reason: too late for 11.2 Priority Requester: Important Requested by: Marc Ruehrschneck (macrue) Partner organization: openSUSE.org Description: Support for MDRAID External Metadata ISW for raid 0, 1, 10 and 5, 6 (??). User should have a choice between DMRAID and MDRAID or have no DMRAID support. This feature request has three aspects: 1) Detection of RAID arrays and platform capabilities Currently SLES can detect raid arrays but it does not confirm whether raid is enabled in the platform BIOS. If raid support has been disabled in the BIOS then arrays should not be presented as candidates for installation Currently "mdadm --detail-platform -e imsm" could be used for this detection as it returns true when the platform has Intel(R) Matrix Storage Manager support enabled. 2) Creating an initrd with support for assembling ISW raid arrays This has dependencies on how FR#781 is resolved (mdp versus kpartx) and needs support for handling the metadata dirty bit FR#782. At a minimum it involves adding something akin to the following commands to the initrd init script: ... mdadm -Asc mdadm.conf mount /dev/md/Volume0p1 /sysroot mdmon --switch-root /sysroot /dev/md/imsm0 ... 3) Installing the bootloader on a RAID device Fortunately the version of grub in SLES11-beta6 seems to already understand/expect partitionable md arrays as the following grub commands: root (hd0,0) setup (hd0) ...ends in a failure to access /dev/md/Volume0p1. So this may add weight to the mdp case for FR#781. Adding a link to the kpartx partition, that SLES11 currently creates, allows this to grub installation to complete successfully. However, this required hand editing of /boot/grub/device.map so the final solution will probably require a utility to dump the grub device to raid device mapping, or the restriction that the raid device must be grub device (hd0). Business case (Partner benefit): openSUSE.org: Enable feature parity with the Windows IMSM stack for Linux customers Discussion: #6: Matthias Eckermann (mge1512) (2009-09-07 13:08:16) As long as Intel is helping us, we should not reject this. #11: Arvin Schnell (aschnell) (2009-11-10 11:55:12) I have now merged the code from Intel to the YaST SLE11 SP1 code. Unfortunately there are still some open issues discovered lately during development, e.g. modification to mdadm.conf and support for udev ids. Also the code has never been tested during installation so expect bug reports. + #12: Thorsten Kukuk (kukuk) (2009-11-25 11:18:35) (reply to #11) + Does this mean we can clos this as done and handle the rest via + bugzilla? If yes, please close. -- openSUSE Feature: https://features.opensuse.org/305883

1 0

[openFATE 302306] Reorganization of YaST control center
by fate_noreply＠suse.de 25 Nov '09

25 Nov '09

Feature changed by: Karl Eichwalder (keichwa) Feature #302306, revision 73 Title: Reorganization of YaST control center openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-07-03 17:08:02 reject reason: Postponing, we are running out of time. Priority Requester: Mandatory openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-04-25 15:09:31 reject reason: Needs more discussion. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.1: Rejected by Federico Lucifredi (flucifredi) reject date: 2008-07-18 18:56:09 reject reason: postponing as per engineering's request. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.2: Rejected by Jiri Srain (jsrain) reject date: 2009-07-17 10:19:44 reject reason: Let's do it early in the 11.2 development cycle to have feedback from Alpha snapshots and be able to adjust. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.3: Evaluation Priority Requester: Mandatory Projectmanager: Important Requested by: Martin Schmidkunz (mschmidkunz) Description: As many users (even the experienced ones) find the current organization of YaST modules confusing a reorganization is needed. We have conducted a usability study where experienced users sorted the YaST modules. So I would really ask to take advantage of these data. You find the data and some thoughts about a possible re-categorization on: http://en.opensuse.org/YaST_Control_Center_-_Card_Sort_Study The reorganization would affect the sorting and presentation, some labeling issues, the use of a consistent icon set, the use of tool tips and an enhancment of search One possible solution would be to organize it similar to the GNOME configuration center: I already heard that it might be mandatory to present AppArmor as an extra section (which in my opinion would be not advisable from a usability perspective, but if it is mandatory, then we have to add it as an extra section). I also thought that some YaST modules (e.g. keyboard, mouse, DNS, Hostname) are doublicated but it turned out, that this makes sense for SLES. Still I suggest combining the modules "user management" and "group management" into a single module called "User and Group Management". This makes sense because opening "user management" and "group management" opens the same module but only show a different view. Documentation Impact: This would require a lot of changes throughout the manuals. Discussion: #1: Tanja Roth (ta-ro) (2007-05-30 14:33:36) Would a reorganization apply to both KDE and GNOME desktop, then? Whatever a new YaST structure would look like, from a doc perspective it would be important that YaST structure and appearance are in sync for both desktops as we strive to use a "common doc base" for both desktops whereever possible to reduce efforts and costs. As reorganization of YaST would require many changes throughout our manuals, we cannot afford to additionally maintain different "flavors" of YaST chapters for KDE/GNOME. Apart from that, consistent structure and appearance of YaST in both desktops would also be a benefit for users. #2: Stanislav Visnovsky (visnov) (2007-06-12 11:40:45) Sigi, is the card study finished now? Where can we find the results? #3: Martin Schmidkunz (mschmidkunz) (2007-06-12 13:58:58) > Would a reorganization apply to both KDE and GNOME desktop, then? Yes. Exactly for the reasons you named, Tanja :-) By the way, a reorganization of YaST control center already took place in SLES 10 SP1. This solution is similar to what Sigi and I suggested. Perhaps it would be a good idea to take the YaST control center as it is in SLES 10 SP1, improve it a little and implement its design into all our products. What do you think about that? #4: Stanislav Visnovsky (visnov) (2007-06-12 14:00:46) (reply to #3) There was no reorganization for SLE10 SP1. The only change was introduction of slab-based GNOME control center for YaST. The categorization, description and module lists did not change and are shared between KDE and GNOME control centers. #5: Martin Schmidkunz (mschmidkunz) (2007-06-12 18:01:19) I am sorry for a missunderstanding. I meant that we should take the current "GNOME control centre" - like design of the YaST control centre in SLES 10 SP 1 as a base for a redesign of the YaST control centre in our other products. Additionally to that, we should discuss (and perform) a reorganization of modules. #7: Federico Lucifredi (flucifredi) (2007-06-29 17:59:43) (reply to #5) This is worth pursuing, I am no UX expert, but if we can make it easier for users to find things, we should. A reorganization should be well thought-out, so that we break the existing habits *only once*, we should not be reshuffling things too often. #8: Siegfried Olschner (sdolschn) (2007-07-03 12:35:30) The results of the the cardsort study are available at: http://en.opensuse.org/YaST_Control_Center_-_Card_Sort_Study The subjects (N=~30) have been "Experts", so you can transfer the results to a new openSUSE YaST Control Center. The cluster trees with 2 different statistical options show only one difference: - ISDN, Modem, DSL, Network => Hardware - ISDN, Modem, DSL, Network => Network see http://en.opensuse.org/YaST_Control_Center_-_Card_Sort_Study#Illustrative_M… I'm just writing a sumary. This section is placed at the top of the page. #9: Siegfried Olschner (sdolschn) (2007-07-03 12:39:23) I got only 2-3 NOT-Expert users in the sample. Their results are not presented on the page. But it's clear, they separated out cards like: VLM, iSCSI Initiator, Powertweak, VNC, Sudo, AppArmor, LDAP, etc., etc. #10: Siegfried Olschner (sdolschn) (2007-07-06 10:05:23) Some mockups available at: http://en.opensuse.org/YaST_Control_Center_-_Card_Sort_Study#Sorting_and_pr… #11: Martin Schmidkunz (mschmidkunz) (2007-11-29 13:50:55) Some additional mock ups and thoughs about that topic are available at: http://en.opensuse.org/YaST/Development/New_Control_Center #13: Martin Schmidkunz (mschmidkunz) (2008-02-11 15:24:24) One other suggestion was influenced by the KDE 4 control center: http://en.opensuse.org/YaST/Development/New_Control_Center/YaST_KDEstyle The main concerns with these mock ups are: * information overload * "search" is somehow meaningless if it isn't provided by some kind of thesaurus #15: Berthold Gunreben (azouhr) (2008-04-09 12:52:12) I don't know if this is just too late, but for me the only design that looks like a real step forward from all the designs on http://en.opensuse.org/YaST/Development/New_Control_Center/ is http://en.opensuse.org/YaST/Development/New_Control_Center/YaST_System_Navi… I really like this approach. Please don't just create huge lists of modules, or preselected lists of modules that never can meet the customers needs. #16: Duncan Mac-Vicar (dmacvicar) (2008-04-24 14:56:14) This feature was on impl. But limited resources and refocus on PackageKit froze development. Passing back to Stano. #17: Federico Lucifredi (flucifredi) (2008-06-13 19:49:56) lets figure out a plan and get it done this time :) #20: Martin Schmidkunz (mschmidkunz) (2007-09-29 03:17:48) As there is some negative feedback from the KDE 4 personal settings menu (https://bugzilla.novell.com/show_bug.cgi?id=431432) maybe we should take it into account when talking about a YaST control center redesign. BTW: what is the status on this feature request? #21: Thomas Göttlicher (tgoettlicher) (2008-10-23 17:03:56) (reply to #20) Thanks for this hint. Development on this featrue is postponed. #22: evamaria fuchs (nefuchs) (2009-01-22 17:49:48) Currently we are conducting usability tests, see: http://en.opensuse.org/YaST/Development/New_Control_Center#Usability_Tests #24: Karl Eichwalder (keichwa) (2009-05-08 07:37:16) For what's worth, things got worse in the meantime ;) This feature needs to be split into 2 or 3 subfeatures: * Improve labels (e.g., "/etc/sysconfig Editor" -> "Sysconfig Editor"). * Reorganize groups: Move items from "Other" to Miscellaneous, split Network Services into Network Servers and Network Clients, make the Apparmor entries one entry and move it to Security, make Virtualization entries one entry and move it to System, move Hostnames from Network Services to Network Devices and rename Network Devices to "Network Devices and Hostnames". * Improve the UI. The Gnome CC is rahter pointless because its left navigation (?) is just superfluous (ok, there is now "Common Tasks"...). Because YaST contains more groups and especially entries, we need a way to hide or collapse groups completely. (I do not like the KDE idea just to display a subset of the entries of a group.) BTW, the worst thing about yast's gtk ui is the idea of sorting groups alphabetically. In English, happily "Hardware" comes before "Miscellaneous"... #28: Bart Otten (bartotten) (2009-11-08 14:19:50) (reply to #24) +1 The AppArmor-group is annoying me for a long time. When it came into openSUSE I allready filed a bugreport (FATE was not openFATE yet). I think there are still some lessons in the card sort study. #25: jimbo bigcreed (dimble_thricefoon) (2009-06-04 16:24:54) the split between kcontrol and yast is confusing #26: Rémy Marquis (spyhawk) (2009-06-05 02:22:02) (reply to #25) This issue has already been discussed here : http://duncan.mac-vicar.com/blog/archives/452 #27: jimbo bigcreed (dimble_thricefoon) (2009-06-17 16:10:31) (reply to #26) cheers for the info. as long as they provide a non-confusing synthesis of the two related system management functions in a native QT4.5 environment i will be happy. #29: Atri Bhattacharya (badshah400) (2009-11-25 00:55:36) In my opinion, it would be nice to split up YaST's Control Centre into two tabs 1) Basic tasks: This tab should show a limited number of tasks (not modules) used frequently by a typical desktop user. The list might include things like: Set up a printer, Set up a TV card, Check for update, Install/uninstall software, Change system-wide network proxy, Configure date and Time, Add/remove user, manage network settings, view release notes, etc. Tasks might also be grouped into categories like hardware, etc. 2) Advanced view: This is a separate tab that shows all the modules categorised into groups. This is equivalent to the present control- centre view. By not presenting at first view a large number of icons with complicated names and advanced functionality (e.g. Kerberos client, AppArmor, Remote administration-VNC, etc.) the control-centre will prevent a typical desktop user from being overwhelmed, which happens with the present view. The task based list will also help in the sense that one generally thinks in terms of tasks when he/she starts up YaST to configure something. The advanced-view is also present (could use a check-box that says show advanced view by default in YaST for experienced people) for all other modules that might be necessary for specialised usage (like the kerberos client). The present YaST Control Centre is overwhelming for a typical desktop user. Reorganising it so that it shows a task-based list at first view will help regular users appreciate the power of YaST and also importantly its simplicity. It is imperative that we concentrate on the average Joe desktop user in streamlining the interface while keeping in mind its versatility and strengths for the experienced user as well. I believe a reorganisation of YaST's interface along these lines will achieve that. + #30: Karl Eichwalder (keichwa) (2009-11-25 09:09:31) (reply to #29) + The idea is quite good, but I'd avoid tabs. + I'd add two additional additional groups ("Favorites" and "Basics") and + list them at the top of the left pane. + "Favorites" are meant to be populated by the user, just add two or + three entries to make look it nice. "Basics" should contain 8 or 10 + entries such as "Install/Remove Software", "Network Config", "Update + Config", etc. + As a third group you could add "Recent Modules"... + After these two are three groups add a separator. -- openSUSE Feature: https://features.opensuse.org/302306

1 0

[openFATE 302306] Reorganization of YaST control center
by fate_noreply＠suse.de 24 Nov '09

24 Nov '09

Feature changed by: Atri Bhattacharya (badshah400) Feature #302306, revision 72 Title: Reorganization of YaST control center openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-07-03 17:08:02 reject reason: Postponing, we are running out of time. Priority Requester: Mandatory openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-04-25 15:09:31 reject reason: Needs more discussion. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.1: Rejected by Federico Lucifredi (flucifredi) reject date: 2008-07-18 18:56:09 reject reason: postponing as per engineering's request. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.2: Rejected by Jiri Srain (jsrain) reject date: 2009-07-17 10:19:44 reject reason: Let's do it early in the 11.2 development cycle to have feedback from Alpha snapshots and be able to adjust. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.3: Evaluation Priority Requester: Mandatory Projectmanager: Important Requested by: Martin Schmidkunz (mschmidkunz) Description: As many users (even the experienced ones) find the current organization of YaST modules confusing a reorganization is needed. We have conducted a usability study where experienced users sorted the YaST modules. So I would really ask to take advantage of these data. You find the data and some thoughts about a possible re-categorization on: http://en.opensuse.org/YaST_Control_Center_-_Card_Sort_Study The reorganization would affect the sorting and presentation, some labeling issues, the use of a consistent icon set, the use of tool tips and an enhancment of search One possible solution would be to organize it similar to the GNOME configuration center: I already heard that it might be mandatory to present AppArmor as an extra section (which in my opinion would be not advisable from a usability perspective, but if it is mandatory, then we have to add it as an extra section). I also thought that some YaST modules (e.g. keyboard, mouse, DNS, Hostname) are doublicated but it turned out, that this makes sense for SLES. Still I suggest combining the modules "user management" and "group management" into a single module called "User and Group Management". This makes sense because opening "user management" and "group management" opens the same module but only show a different view. Documentation Impact: This would require a lot of changes throughout the manuals. Discussion: #1: Tanja Roth (ta-ro) (2007-05-30 14:33:36) Would a reorganization apply to both KDE and GNOME desktop, then? Whatever a new YaST structure would look like, from a doc perspective it would be important that YaST structure and appearance are in sync for both desktops as we strive to use a "common doc base" for both desktops whereever possible to reduce efforts and costs. As reorganization of YaST would require many changes throughout our manuals, we cannot afford to additionally maintain different "flavors" of YaST chapters for KDE/GNOME. Apart from that, consistent structure and appearance of YaST in both desktops would also be a benefit for users. #2: Stanislav Visnovsky (visnov) (2007-06-12 11:40:45) Sigi, is the card study finished now? Where can we find the results? #3: Martin Schmidkunz (mschmidkunz) (2007-06-12 13:58:58) > Would a reorganization apply to both KDE and GNOME desktop, then? Yes. Exactly for the reasons you named, Tanja :-) By the way, a reorganization of YaST control center already took place in SLES 10 SP1. This solution is similar to what Sigi and I suggested. Perhaps it would be a good idea to take the YaST control center as it is in SLES 10 SP1, improve it a little and implement its design into all our products. What do you think about that? #4: Stanislav Visnovsky (visnov) (2007-06-12 14:00:46) (reply to #3) There was no reorganization for SLE10 SP1. The only change was introduction of slab-based GNOME control center for YaST. The categorization, description and module lists did not change and are shared between KDE and GNOME control centers. #5: Martin Schmidkunz (mschmidkunz) (2007-06-12 18:01:19) I am sorry for a missunderstanding. I meant that we should take the current "GNOME control centre" - like design of the YaST control centre in SLES 10 SP 1 as a base for a redesign of the YaST control centre in our other products. Additionally to that, we should discuss (and perform) a reorganization of modules. #7: Federico Lucifredi (flucifredi) (2007-06-29 17:59:43) (reply to #5) This is worth pursuing, I am no UX expert, but if we can make it easier for users to find things, we should. A reorganization should be well thought-out, so that we break the existing habits *only once*, we should not be reshuffling things too often. #8: Siegfried Olschner (sdolschn) (2007-07-03 12:35:30) The results of the the cardsort study are available at: http://en.opensuse.org/YaST_Control_Center_-_Card_Sort_Study The subjects (N=~30) have been "Experts", so you can transfer the results to a new openSUSE YaST Control Center. The cluster trees with 2 different statistical options show only one difference: - ISDN, Modem, DSL, Network => Hardware - ISDN, Modem, DSL, Network => Network see http://en.opensuse.org/YaST_Control_Center_-_Card_Sort_Study#Illustrative_M… I'm just writing a sumary. This section is placed at the top of the page. #9: Siegfried Olschner (sdolschn) (2007-07-03 12:39:23) I got only 2-3 NOT-Expert users in the sample. Their results are not presented on the page. But it's clear, they separated out cards like: VLM, iSCSI Initiator, Powertweak, VNC, Sudo, AppArmor, LDAP, etc., etc. #10: Siegfried Olschner (sdolschn) (2007-07-06 10:05:23) Some mockups available at: http://en.opensuse.org/YaST_Control_Center_-_Card_Sort_Study#Sorting_and_pr… #11: Martin Schmidkunz (mschmidkunz) (2007-11-29 13:50:55) Some additional mock ups and thoughs about that topic are available at: http://en.opensuse.org/YaST/Development/New_Control_Center #13: Martin Schmidkunz (mschmidkunz) (2008-02-11 15:24:24) One other suggestion was influenced by the KDE 4 control center: http://en.opensuse.org/YaST/Development/New_Control_Center/YaST_KDEstyle The main concerns with these mock ups are: * information overload * "search" is somehow meaningless if it isn't provided by some kind of thesaurus #15: Berthold Gunreben (azouhr) (2008-04-09 12:52:12) I don't know if this is just too late, but for me the only design that looks like a real step forward from all the designs on http://en.opensuse.org/YaST/Development/New_Control_Center/ is http://en.opensuse.org/YaST/Development/New_Control_Center/YaST_System_Navi… I really like this approach. Please don't just create huge lists of modules, or preselected lists of modules that never can meet the customers needs. #16: Duncan Mac-Vicar (dmacvicar) (2008-04-24 14:56:14) This feature was on impl. But limited resources and refocus on PackageKit froze development. Passing back to Stano. #17: Federico Lucifredi (flucifredi) (2008-06-13 19:49:56) lets figure out a plan and get it done this time :) #20: Martin Schmidkunz (mschmidkunz) (2007-09-29 03:17:48) As there is some negative feedback from the KDE 4 personal settings menu (https://bugzilla.novell.com/show_bug.cgi?id=431432) maybe we should take it into account when talking about a YaST control center redesign. BTW: what is the status on this feature request? #21: Thomas Göttlicher (tgoettlicher) (2008-10-23 17:03:56) (reply to #20) Thanks for this hint. Development on this featrue is postponed. #22: evamaria fuchs (nefuchs) (2009-01-22 17:49:48) Currently we are conducting usability tests, see: http://en.opensuse.org/YaST/Development/New_Control_Center#Usability_Tests #24: Karl Eichwalder (keichwa) (2009-05-08 07:37:16) For what's worth, things got worse in the meantime ;) This feature needs to be split into 2 or 3 subfeatures: * Improve labels (e.g., "/etc/sysconfig Editor" -> "Sysconfig Editor"). * Reorganize groups: Move items from "Other" to Miscellaneous, split Network Services into Network Servers and Network Clients, make the Apparmor entries one entry and move it to Security, make Virtualization entries one entry and move it to System, move Hostnames from Network Services to Network Devices and rename Network Devices to "Network Devices and Hostnames". * Improve the UI. The Gnome CC is rahter pointless because its left navigation (?) is just superfluous (ok, there is now "Common Tasks"...). Because YaST contains more groups and especially entries, we need a way to hide or collapse groups completely. (I do not like the KDE idea just to display a subset of the entries of a group.) BTW, the worst thing about yast's gtk ui is the idea of sorting groups alphabetically. In English, happily "Hardware" comes before "Miscellaneous"... #28: Bart Otten (bartotten) (2009-11-08 14:19:50) (reply to #24) +1 The AppArmor-group is annoying me for a long time. When it came into openSUSE I allready filed a bugreport (FATE was not openFATE yet). I think there are still some lessons in the card sort study. #25: jimbo bigcreed (dimble_thricefoon) (2009-06-04 16:24:54) the split between kcontrol and yast is confusing #26: Rémy Marquis (spyhawk) (2009-06-05 02:22:02) (reply to #25) This issue has already been discussed here : http://duncan.mac-vicar.com/blog/archives/452 #27: jimbo bigcreed (dimble_thricefoon) (2009-06-17 16:10:31) (reply to #26) cheers for the info. as long as they provide a non-confusing synthesis of the two related system management functions in a native QT4.5 environment i will be happy. + #29: Atri Bhattacharya (badshah400) (2009-11-25 00:55:36) + In my opinion, it would be nice to split up YaST's Control Centre into + two tabs + 1) Basic tasks: This tab should show a limited number of tasks (not + modules) used frequently by a typical desktop user. The list might + include things like: Set up a printer, Set up a TV card, Check for + update, Install/uninstall software, Change system-wide network proxy, + Configure date and Time, Add/remove user, manage network settings, view + release notes, etc. Tasks might also be grouped into categories like + hardware, etc. + 2) Advanced view: This is a separate tab that shows all the modules + categorised into groups. This is equivalent to the present control- + centre view. + By not presenting at first view a large number of icons with + complicated names and advanced functionality (e.g. Kerberos client, + AppArmor, Remote administration-VNC, etc.) the control-centre will + prevent a typical desktop user from being overwhelmed, which happens + with the present view. The task based list will also help in the sense + that one generally thinks in terms of tasks when he/she starts up YaST + to configure something. The advanced-view is also present (could use a + check-box that says show advanced view by default in YaST for + experienced people) for all other modules that might be necessary for + specialised usage (like the kerberos client). + The present YaST Control Centre is overwhelming for a typical desktop + user. Reorganising it so that it shows a task-based list at first view + will help regular users appreciate the power of YaST and also + importantly its simplicity. It is imperative that we concentrate on the + average Joe desktop user in streamlining the interface while keeping in + mind its versatility and strengths for the experienced user as well. I + believe a reorganisation of YaST's interface along these lines will + achieve that. -- openSUSE Feature: https://features.opensuse.org/302306

1 0

[New: openFATE 308394] Luasql
by fate_noreply＠suse.de 23 Nov '09

23 Nov '09

Feature added by: Bill Weidman (bweidman) Feature #308394, revision 1 Title: Luasql Package Wishlist: Unconfirmed Priority Requester: Important Requested by: Bill Weidman (bweidman) Description: Please create LuaSQL packages for the different database drivers and have them in the standard repo. http://www.keplerproject.org/luasql/ Thanks! -- openSUSE Feature: https://features.opensuse.org/308394

1 1

[openFATE 307613] Add Action Code Fields and Generate Email Texts According to Action Code Field
by fate_noreply＠suse.de 23 Nov '09

23 Nov '09

Feature added by: Scott Couston (zczc2311) Feature #307613, revision 1 Title: Add Action Code Fields and Generate Email Texts According to Action Code Field openFATE: Unconfirmed Priority Requester: Important Requested by: Scott Couston (zczc2311) Description: Currently we open a new Feature request and the creator is not aware of any other action taken or added to the feature request. If a Feature is Closed due Dupe or invalid the creator is never aware of this. Other changes to the feature become lost to the original author. No one who contributes to the feature request ever gets an auto generated message as in current Bugzilla notifications. If the feature request is closed the author has no idea this has occured. Can we create an Action Code Field in each modification entry of any feature request. Here we can have default actions such as 'NEW' when a feature is created and the authors email added in the same manner as Bugzilla. Each additional comment can have a default Action code of 'ADDED-INFO' and add the authors email to this new entry. Each addition that clarifies or redefined the feature can have a 'CLARIFIED' or REDEFINED' action code field. The generation of messages of anything added to the feature request is subordinate and equal to the level of added entries and action code dependant. For example. The author of the creation of a feature will recieve email notification of ever addition to the feature. Anyone who add a third addition to the feature receives an email message and all subordinate entries back as far as the original author. Action code fields can be via Drop down menu box and the logic of selection of action code must be enforced. For example the First creation of a feature adds a mandatory NEW action code. This action would be the only non greyed out selection from the drop down list. The next entry, if the entry is to suggest 'REDEFINED' by drop down selection, would have 'NEW' greyed out and not accessible and leave 'REDEFINED' or 'CLARIFIED' or 'NEGATED'....etc available from drop down list. Once a new entry has been added to a feature request the previous entry action code field is not accessible. If the feature request gets 'ADDED-FUNCTION' and thereby put into production, no further entry's should be permitted and the feature locked with the exception of an added entry with the action code of 'COMMENT' from the drop down. Again message generation is equal and subordinate to the entry being added. For each and every Branch of comment or test-case a default action code filed should be maintained. Comments Please and I will manually check on this feature request's disposition. Scott -- openSUSE Feature: https://features.opensuse.org/307613

1 5

[openFATE 305551] [Beta5] Document YaST RELAX NG Schema
by fate_noreply＠suse.de 23 Nov '09

23 Nov '09

Feature changed by: Frank Sundermeyer (fsundermeyer) Feature #305551, revision 17 Title: [Beta5] Document YaST RELAX NG Schema openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-07-16 16:26:24 reject reason: out of resources for 11.2. Priority Requester: Desirable Projectmanager: Important openSUSE-11.3: Candidate Priority Requester: Desirable Projectmanager: Mandatory Requested by: Thomas Schraitle (thomas-schraitle) Partner organization: openSUSE.org Description: According to bnc#455994 (comment #17) Lukas Ocilka suggested to create a FATE entry for this purpose. Background: The YaST DTD for /etc/YaST2/firstboot.xml and the like is outdated and lead to invalid XML files. The DTD is/was rewritten as a RELAX NG Schema but elements, attributes, and attribute values are not documented yet. - Documentation Impact: - yes Business case (Partner benefit): openSUSE.org: * Documented RNG schema supports XML editors in showing tool tips during the writing of a XML file. * WIth the help of XSLT a summary can be created automatically. > reduces costs Discussion: #1: Lukas Ocilka (locilka) (2009-01-16 16:32:28) The XML format of a control file is currently documented at http://forgeftp.novell.com/yast/doc/SL11.1/tdg/inst_in_general_chap.html (generated from manually written docbook file) nevertheless this means that it has to be done at two places at once: the RELAX NG schema and its documentation itself. Having the documentation source insite the RELAX NG schema would halp to keep the documentation in sync. #5: Thomas Schraitle (thomas-schraitle) (2009-09-09 08:54:54) Just for the record: See a documented example of a RELAX NG schema in http://gitorious.org/kiwi/kiwi/blobs/master/modules/KIWISchema.rnc (This is the work that I've done with Marcus.) -- openSUSE Feature: https://features.opensuse.org/305551

1 0

[openFATE 306356] Icons in YaST: Use /usr/share/icons/hicolor/ as a fallback
by fate_noreply＠suse.de 23 Nov '09

23 Nov '09

Feature changed by: Katarina Machalkova (kmachalkova) Feature #306356, revision 14 Title: Icons in YaST: Use /usr/share/icons/hicolor/ as a fallback openSUSE-11.2: Done Priority Requester: Important Projectmanager: Important Requested by: Lukas Ocilka (locilka) Partner organization: openSUSE.org Description: YaST icons are expected to be in /usr/share/YaST2/theme/current/icons/ directory but the list of icons is fixed because the current is a symlink to the currently installed and selected theme-directory which is different for openSUSE or SLES. If another (e.g., 3rd party) YaST module wants to add its own icon, it has to put it into the current directory which will change when using another YaST theme. The proposal is simple: If an icon is not found in the current theme, try to use /usr/share/icons/hicolor/ as a fallback. Business case (Partner benefit): openSUSE.org: 3rd party add-ons with YaST modules, Our own add-ons with YaST modules (SMT, OES)... Discussion: #1: Christoph Thiel (cthiel1) (2009-04-20 17:30:28) Makes a lot of sense to me with regard to appliances and custom YaST themes. #2: Katarina Machalkova (kmachalkova) (2009-07-29 13:00:38) Done in yast2-control-center-qt #3: Katarina Machalkova (kmachalkova) (2009-07-29 13:09:14) Done also in yast2-libyui and yast2-qt. Instead of one global icon search path there can now be several search paths and they're traversed until the correct icon is found. This is done transparently for UIs on libyui level (for selection-like widgets). Note I've kept the global search path in mostly for compatibility reasons, in order not to break Gtk UI (since I don't speak Gtk and can't adjust the code myself) but I'd like to drop it eventually. Also icons in IconButton type of widget currently do not work in Gtk, but that does not matter, as they're not used anywhere in YaST. Once the Gtk part is settled, we can set this to 'done' + #6: Katarina Machalkova (kmachalkova) (2009-11-23 15:24:17) + yast2-qt, yast2-qt-pkg and yast2-libyui got backported to SLE11SP1 as a + whole within package mgmt stack backport, so we got desired + functionality there for free. + Now backported also to Qt3 control centre. -- openSUSE Feature: https://features.opensuse.org/306356

1 0

[New: openFATE 308362] exposing openFate by RSS feeds
by fate_noreply＠suse.de 23 Nov '09

23 Nov '09

Feature added by: Roberto Mannai (robermann79) Feature #308362, revision 1 Title: exposing openFate by RSS feeds openFATE: Unconfirmed Priority Requester: Desirable Requested by: Roberto Mannai (robermann79) Partner organization: openSUSE.org Description: Please expose the features lists via RSS/atom feeds. Business case (Partner benefit): openSUSE.org: It would be a more convenient way of "staying tuned" on new requests, instead of having to check manually the web dashboard. -- openSUSE Feature: https://features.opensuse.org/308362

1 4

[New: openFATE 308387] Show only GUI-application selection mode in packager manager
by fate_noreply＠suse.de 23 Nov '09

23 Nov '09

Feature added by: Mindaugas Baranauskas (embar-) Feature #308387, revision 1 Title: Show only GUI-application selection mode in packager manager openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Mindaugas Baranauskas (embar-) Description: In Ubuntu is simple way to install GUI program. In Mandriva packager manager is option to show only GUI programs (with icons). I think, we should to it also – it will be useful. -- openSUSE Feature: https://features.opensuse.org/308387

1 0