December 2008 - openSUSE Features - openSUSE Mailing Lists

[openFate 305550] Port of YaST Qt Control Center to Qt4
by fate_noreply＠suse.de 14 Aug '09

14 Aug '09

Feature added by: Stephan Binner <stbinner(a)novell.com> Feature #305550, revision 1, last change by Title: Port of YaST Qt Control Center to Qt4 openSUSE-11.2: New Priority Requester: Important Requested by: Stephan Binner <stbinner(a)novell.com> Partner organization: openSUSE.org Description: The YaST Qt Control Center is one of the few remaining parts of the desktop still requiring Qt3. It should be ported to Qt4. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305550

1 23

[openFate 305146] Use old system network configuration when updating instead of demanding a new one
by fate_noreply＠suse.de 24 Jun '09

24 Jun '09

Feature added by: Lukas Ocilka <locilka(a)novell.com> Feature #305146, revision 1, last change by Title: Use old system network configuration when updating instead of demanding a new one openSUSE-11.2: New Priority Requester: Desirable Requested by: Pacho Ramos <pacho(a)condmat1.ciencias.uniovi.es> Partner organization: openSUSE.org Description: Currently, when I try to update from opensuse 10.3 to 11.0 with DVD and I want to add network repositories, I have to configure again my network for opensuse installer even when it is already configured on my opensuse-10.3 I think that would be much better try to use network configuration from old installation and only ask user if a problem occurs Business case (Partner benefit): openSUSE.org: System update from media: Start installation / Update, select network-based repositories to be used, you will be asked to configure the network. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305146

1 5

[openFate 305272] Definition in the Yast2 samba server module for "workgroup" host
by fate_noreply＠suse.de 28 May '09

28 May '09

Feature added by: Lukas Ocilka <locilka(a)novell.com> Feature #305272, revision 1, last change by Title: Definition in the Yast2 samba server module for "workgroup" host openSUSE-11.2: New Priority Requester: Desirable Requested by: Andreas van dem Helge <andrew(a)joako.net> Partner organization: openSUSE.org Description: Add a definition in the samba server module for "workgroup" host. I.E. in a SOHO it isn't always necessary to setup a true "domain" server, however if there were a set of options for things like "LMB" aka "local master browser" and a quick set of clicks to join a "Workgrp" as a client. this tutorial highlights the amount of script editing that could be avoided if the samba server were more "workgroup" friendly http://www.swerdna.net.au/linhowtolanprimer.html#samba (http://www.swerdna.net.au/linhowtolanprimer.html#samba) References: Originally reported as BNC #420766 (https://bugzilla.novell.com/show_bug.cgi?id=420766) -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305272

1 3

[openFate 305170] openFATE test
by fate_noreply＠suse.de 05 Mar '09

05 Mar '09

Feature added by: Michael Loeffler <michl(a)novell.com> Feature #305170, revision 1, last change by Title: openFATE test openSUSE-11.1: Evaluation Priority Requester: Mandatory Requested by: Michael Loeffler <michl(a)novell.com> Partner organization: openSUSE.org Description: test Business case (Partner benefit): openSUSE.org: sdf -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305170

1 5

[openFate 305162] Support Ext4 in Grub
by fate_noreply＠suse.de 18 Jan '09

18 Jan '09

Feature added by: coly li <coyli(a)novell.com> Feature #305162, revision 1, last change by Title: Support Ext4 in Grub openSUSE-11.1: New Priority Requester: Important Requested by: coly li <coyli(a)novell.com> Partner organization: openSUSE.org Description: Ext4 is in upstream kernel already. But since lack of grub legacy supporting, Ext4 can not be used as booting partition. By effort of opensuse's GSoC project, Ext4 stage1.5 is aded into grub legacy. We should consider adding the feature in next opensuse release. Code can be found from http://code.google.com/p/grub4ext4/downloads/list -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305162

1 10

[openFate 305591] Define purpose for each project
by fate_noreply＠suse.de 19 Dec '08

19 Dec '08

Feature changed by: Pavol Rusnak <prusnak(a)novell.com> Feature #305591, revision 3 Title: Define purpose for each project Buildservice: New Priority Requester: Important Requested by: Pavol Rusnak <prusnak(a)novell.com> + Partner organization: openSUSE.org Description: http://lists.opensuse.org/opensuse-buildservice/2008-12/msg00056.html * define purpose for each project, like: * add-on package * fresh packages + libraries (eg. games) * bleeding edge packages (eg. zypp:svn) * backports for older distributions (eg. zypp:Backport) * playground (eg. all home projects) - this sets users expectations - purpose could be indicated by naming conventions, or even better by project flags - purpose must be shown in the search result for this method to work -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305591

1 0

[openFate 302306] Reorganization of YaST control center
by fate_noreply＠suse.de 16 Dec '08

16 Dec '08

Feature changed by: Duncan Mac-Vicar <dmacvicar(a)novell.com> Feature #302306, revision 38 Title: Reorganization of YaST control center openSUSE-10.3: Rejected by Stanislav Visnovsky <visnov(a)novell.com> 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(a)novell.com> 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(a)novell.com> reject date: 2008-07-18 18:56:09 reject reason: postponing as per engineering's request. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.2: New Priority Requester: Mandatory Requested by: Martin Schmidkunz <mschmidkunz(a)novell.com> + Partner organization: openSUSE.org 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 <taroth(a)novell.com> (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(a)novell.com> (2007-06-12 11:40:45) Sigi, is the card study finished now? Where can we find the results? #3: Martin Schmidkunz <mschmidkunz(a)novell.com> (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(a)novell.com> (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(a)novell.com> (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(a)novell.com> (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 <siegfried.olschner(a)novell.com> (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 <siegfried.olschner(a)novell.com> (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 <siegfried.olschner(a)novell.com> (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(a)novell.com> (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(a)novell.com> (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 <bg(a)novell.com> (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(a)novell.com> (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(a)novell.com> (2008-06-13 19:49:56) lets figure out a plan and get it done this time :) #19: Federico Lucifredi <flucifredi(a)novell.com> (2008-07-18 18:55:46) PM-Priority for product openSUSE-11.1 downgraded from mandatory to important: lowering as per engineering request. #20: Martin Schmidkunz <mschmidkunz(a)novell.com> (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(a)novell.com> (2008-10-23 17:03:56) (reply to #20) Thanks for this hint. Development on this featrue is postponed. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=302306

1 0

[openFate 301791] "Report a bug" a-la-Safari for Mozilla Firefox
by fate_noreply＠suse.de 04 Dec '08

04 Dec '08

Feature changed by: Stefan Behlert <behlert(a)novell.com> Feature #301791, revision 31 Title: "Report a bug" a-la-Safari for Mozilla Firefox openSUSE-11.0: Rejected by Stefan Behlert <behlert(a)novell.com> reject date: 2008-10-14 10:33:33 reject reason: Clearly not done Priority Requester: Mandatory Projectmanager: Desirable Archs: i386, x86-64 openSUSE-11.1: Rejected by Stefan Behlert <behlert(a)novell.com> reject date: 2008-12-03 14:23:26 reject reason: Nothing done for 11.1 Priority Requester: Mandatory Projectmanager: Important - SLED-11: Candidate + openSUSE-11.2: New Priority Requester: Mandatory + SLED-11: Rejected by Stefan Behlert <behlert(a)novell.com> + reject date: 2008-12-04 13:53:50 + reject reason: Not done. + Priority + Requester: Mandatory Projectmanager: Important Archs: i386, x86-64 + SLED-11-SP1: New + Priority + Requester: Mandatory Requested by: Guy Lunardi <glunardi(a)novell.com> Partner organization: openSUSE.org Description: Apple's Safari web browser introduced a really easy for end-users to report public URLs which didn't render properly in Safari. It would be very nice if we could offer something similar for our Firefox. what you should be able to send: - Once Address URL - Description - Problem: other problem, missing content, imcorrect behavior, incorrect aspect, empty page, unable to load the page or unable to connect. - Send screenshot - Send source code Discussion: #1: JP Rosevear <jpr(a)novell.com> (2008-02-28 23:27:20) How is this fundamentally different from Help->Report Broken Website in 2.0.12> I guess code is not sent nor is the screenshot, but this is all the upstream developers are requesting. Or are you intending submission to bugzilla.novell.com? #2: Guy Lunardi <glunardi(a)novell.com> (2008-03-05 18:26:47) (reply to #1) JP, thanks for pointing this out. The solution is very close right now. What it doesn't support is the sharing information for pages that are 'Intranet-based' and not 'Internet-based'. One of our customer may want to report a problem with Firefox with an homegrown application which the developers looking at the results of this submission can't access. Embedding the results (as MTHML or html source) would be the one missing feature. The other thing is that this content probably goes upstream. Should it come to Novell? #3: Gary Ekker <gekker(a)novell.com> (2008-05-09 10:23:42) Michael, does this like something you could do? Or do we need to find another developer? #4: Michael Wolf <maw@please-enter-an-email-address> (2008-05-30 18:27: 09) (reply to #3) Not sure yet, but I'll look into it. #6: Gary Ekker <gekker(a)novell.com> (2008-09-11 19:00:59) Proxying this for Michael: It seems like the best thing to do would be to use what's already in place. The reporting functionality can be configured. The source to the reporter contains the following: | pref("extensions.reporter.privacyURL", "http://reporter.mozilla.org/privacy/"); | pref("extensions.reporter. serviceURL", "http://reporter.mozilla.org/service/0.3/"); They can be changed in about:config, presumably sitewide. (This might need to be hooked into the gconf stuff.) So I think it would be a matter of setting up a hypothetical http://reporter.novell.com/ and/or http://reporter.example.com/. The source for the server-side part of the reporter is at hosted on mozilla cvs and can be checked out with "cvs -d :pserver: anonymous@cvs-mirror.mozilla.org:/cvsroot co mozilla/tools/reporter" The maintainers of said server(s) could then deal with problem reports as seems fit. If we choose in SLED to change the default to the hypothetical http://reporter.novell.com/, it would be trivial to do so via the MozillaFirefox-branding-SLED package. (I don't think this package actually exists yet.) #7: Gary Ekker <gekker(a)novell.com> (2008-09-11 19:01:59) Adding Federico and Stano as we might want to look at this in the context of onstar. #8: Stefan Behlert <behlert(a)novell.com> (2008-10-14 10:34:08) What's the status here? #9: Stefan Behlert <behlert(a)novell.com> (2008-10-24 17:23:17) (reply to #8) Gary, Michael? #10: Stefan Behlert <behlert(a)novell.com> (2008-11-13 23:46:50) Guy, we need to reject this as there was no progress. Gary, could you provide an ECO for that? #11: Stefan Behlert <behlert(a)novell.com> (2008-12-03 14:22:39) PM-Priority for product SLED-11 downgraded from mandatory to important: for retracting. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=301791

1 0

[openFate 301791] "Report a bug" a-la-Safari for Mozilla Firefox
by fate_noreply＠suse.de 03 Dec '08

03 Dec '08

Feature changed by: Stefan Behlert <behlert(a)novell.com> Feature #301791, revision 30 Title: "Report a bug" a-la-Safari for Mozilla Firefox openSUSE-11.0: Rejected by Stefan Behlert <behlert(a)novell.com> reject date: 2008-10-14 10:33:33 reject reason: Clearly not done Priority Requester: Mandatory Projectmanager: Desirable Archs: i386, x86-64 - openSUSE-11.1: Evaluation + openSUSE-11.1: Rejected by Stefan Behlert <behlert(a)novell.com> + reject date: 2008-12-03 14:23:26 + reject reason: Nothing done for 11.1 Priority Requester: Mandatory Projectmanager: Important SLED-11: Candidate Priority Requester: Mandatory Projectmanager: Important Archs: i386, x86-64 Requested by: Guy Lunardi <glunardi(a)novell.com> Partner organization: openSUSE.org Description: Apple's Safari web browser introduced a really easy for end-users to report public URLs which didn't render properly in Safari. It would be very nice if we could offer something similar for our Firefox. what you should be able to send: - Once Address URL - Description - Problem: other problem, missing content, imcorrect behavior, incorrect aspect, empty page, unable to load the page or unable to connect. - Send screenshot - Send source code Discussion: #1: JP Rosevear <jpr(a)novell.com> (2008-02-28 23:27:20) How is this fundamentally different from Help->Report Broken Website in 2.0.12> I guess code is not sent nor is the screenshot, but this is all the upstream developers are requesting. Or are you intending submission to bugzilla.novell.com? #2: Guy Lunardi <glunardi(a)novell.com> (2008-03-05 18:26:47) (reply to #1) JP, thanks for pointing this out. The solution is very close right now. What it doesn't support is the sharing information for pages that are 'Intranet-based' and not 'Internet-based'. One of our customer may want to report a problem with Firefox with an homegrown application which the developers looking at the results of this submission can't access. Embedding the results (as MTHML or html source) would be the one missing feature. The other thing is that this content probably goes upstream. Should it come to Novell? #3: Gary Ekker <gekker(a)novell.com> (2008-05-09 10:23:42) Michael, does this like something you could do? Or do we need to find another developer? #4: Michael Wolf <maw@please-enter-an-email-address> (2008-05-30 18:27: 09) (reply to #3) Not sure yet, but I'll look into it. #6: Gary Ekker <gekker(a)novell.com> (2008-09-11 19:00:59) Proxying this for Michael: It seems like the best thing to do would be to use what's already in place. The reporting functionality can be configured. The source to the reporter contains the following: | pref("extensions.reporter.privacyURL", "http://reporter.mozilla.org/privacy/"); | pref("extensions.reporter. serviceURL", "http://reporter.mozilla.org/service/0.3/"); They can be changed in about:config, presumably sitewide. (This might need to be hooked into the gconf stuff.) So I think it would be a matter of setting up a hypothetical http://reporter.novell.com/ and/or http://reporter.example.com/. The source for the server-side part of the reporter is at hosted on mozilla cvs and can be checked out with "cvs -d :pserver: anonymous@cvs-mirror.mozilla.org:/cvsroot co mozilla/tools/reporter" The maintainers of said server(s) could then deal with problem reports as seems fit. If we choose in SLED to change the default to the hypothetical http://reporter.novell.com/, it would be trivial to do so via the MozillaFirefox-branding-SLED package. (I don't think this package actually exists yet.) #7: Gary Ekker <gekker(a)novell.com> (2008-09-11 19:01:59) Adding Federico and Stano as we might want to look at this in the context of onstar. #8: Stefan Behlert <behlert(a)novell.com> (2008-10-14 10:34:08) What's the status here? #9: Stefan Behlert <behlert(a)novell.com> (2008-10-24 17:23:17) (reply to #8) Gary, Michael? #10: Stefan Behlert <behlert(a)novell.com> (2008-11-13 23:46:50) Guy, we need to reject this as there was no progress. Gary, could you provide an ECO for that? #11: Stefan Behlert <behlert(a)novell.com> (2008-12-03 14:22:39) PM-Priority for product SLED-11 downgraded from mandatory to important: for retracting. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=301791

1 0

[openFate 301791] "Report a bug" a-la-Safari for Mozilla Firefox
by fate_noreply＠suse.de 03 Dec '08

03 Dec '08

Feature changed by: Stefan Behlert <behlert(a)novell.com> Feature #301791, revision 29 Title: "Report a bug" a-la-Safari for Mozilla Firefox openSUSE-11.0: Rejected by Stefan Behlert <behlert(a)novell.com> reject date: 2008-10-14 10:33:33 reject reason: Clearly not done Priority Requester: Mandatory Projectmanager: Desirable Archs: i386, x86-64 openSUSE-11.1: Evaluation Priority Requester: Mandatory Projectmanager: Important SLED-11: Candidate Priority Requester: Mandatory Projectmanager: Important Archs: i386, x86-64 Requested by: Guy Lunardi <glunardi(a)novell.com> Partner organization: openSUSE.org Description: Apple's Safari web browser introduced a really easy for end-users to report public URLs which didn't render properly in Safari. It would be very nice if we could offer something similar for our Firefox. what you should be able to send: - Once Address URL - Description - Problem: other problem, missing content, imcorrect behavior, incorrect aspect, empty page, unable to load the page or unable to connect. - Send screenshot - Send source code Discussion: #1: JP Rosevear <jpr(a)novell.com> (2008-02-28 23:27:20) How is this fundamentally different from Help->Report Broken Website in 2.0.12> I guess code is not sent nor is the screenshot, but this is all the upstream developers are requesting. Or are you intending submission to bugzilla.novell.com? #2: Guy Lunardi <glunardi(a)novell.com> (2008-03-05 18:26:47) (reply to #1) JP, thanks for pointing this out. The solution is very close right now. What it doesn't support is the sharing information for pages that are 'Intranet-based' and not 'Internet-based'. One of our customer may want to report a problem with Firefox with an homegrown application which the developers looking at the results of this submission can't access. Embedding the results (as MTHML or html source) would be the one missing feature. The other thing is that this content probably goes upstream. Should it come to Novell? #3: Gary Ekker <gekker(a)novell.com> (2008-05-09 10:23:42) Michael, does this like something you could do? Or do we need to find another developer? - #4: Michael Wolf <maw(a)novell.com> (2008-05-30 18:27:09) (reply to #3) + #4: Michael Wolf <maw@please-enter-an-email-address> (2008-05-30 18:27: + 09) (reply to #3) Not sure yet, but I'll look into it. #6: Gary Ekker <gekker(a)novell.com> (2008-09-11 19:00:59) Proxying this for Michael: It seems like the best thing to do would be to use what's already in place. The reporting functionality can be configured. The source to the reporter contains the following: | pref("extensions.reporter.privacyURL", "http://reporter.mozilla.org/privacy/"); | pref("extensions.reporter. serviceURL", "http://reporter.mozilla.org/service/0.3/"); They can be changed in about:config, presumably sitewide. (This might need to be hooked into the gconf stuff.) So I think it would be a matter of setting up a hypothetical http://reporter.novell.com/ and/or http://reporter.example.com/. The source for the server-side part of the reporter is at hosted on mozilla cvs and can be checked out with "cvs -d :pserver: anonymous@cvs-mirror.mozilla.org:/cvsroot co mozilla/tools/reporter" The maintainers of said server(s) could then deal with problem reports as seems fit. If we choose in SLED to change the default to the hypothetical http://reporter.novell.com/, it would be trivial to do so via the MozillaFirefox-branding-SLED package. (I don't think this package actually exists yet.) #7: Gary Ekker <gekker(a)novell.com> (2008-09-11 19:01:59) Adding Federico and Stano as we might want to look at this in the context of onstar. #8: Stefan Behlert <behlert(a)novell.com> (2008-10-14 10:34:08) What's the status here? #9: Stefan Behlert <behlert(a)novell.com> (2008-10-24 17:23:17) (reply to #8) Gary, Michael? #10: Stefan Behlert <behlert(a)novell.com> (2008-11-13 23:46:50) Guy, we need to reject this as there was no progress. Gary, could you provide an ECO for that? + #11: Stefan Behlert <behlert(a)novell.com> (2008-12-03 14:22:39) + PM-Priority for product SLED-11 downgraded from mandatory to important: + for retracting. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=301791

1 0