January 2009 - openSUSE Features - openSUSE Mailing Lists

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

30 Jan '09

Feature changed by: Thomas Schmidt (digitaltomm) Feature #302963, revision 16 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 ;)) + #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? -- openSUSE Feature: https://features.opensuse.org/302963

1 0

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

29 Jan '09

Feature changed by: Eric Springer (Erikina) Feature #305296, revision 11 Title: Easy Way to Disable Beagle Completely During Installation openSUSE-11.2: Evaluation Priority Requester: Important Requested by: JP Rosevear (jproseve) Partner organization: openSUSE.org Description: We need to either have beagle off by default and allow a user to enable it the first time they search or provide an install option to turn it off. Relations: - Better Beagle Acceptance (feature/id: 303367) - Easy way to disable beagle completely during install (novell/bugzilla/id: 282678) https://bugzilla.novell.com/show_bug.cgi?id=282678 Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:52:46) I prefer to start with disabled, offer option to run at first search. We are proliferating checkboxes in the installer too much. #2: Kevin Dupuy (kdupuy9) (2009-01-29 23:40:17) I prefer a more sane option than disabling it by default... instead, allow the user to go in and uninstall it from the installation software screen, just as they would any other app (perhaps make 'Desktop Search' pattern, installed by default?) We just need to insure that uninstalling Beagle doesn't throw up any dependency errors. + #3: Eric Springer (erikina) (2009-01-30 00:16:23) + Every single openSUSE install I've done has resulted in beagle being + removed. It slows down the computer, and the firefox extension throws + lots of errors. I'm quite happy with how easy it is to remove, and I + can see why it's useful -- but unless its seriously improved, I think + it should be removed (by default) -- openSUSE Feature: https://features.opensuse.org/305296

1 0

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

29 Jan '09

Feature changed by: Kevin Dupuy (kdupuy9) Feature #305296, revision 9 Title: Easy Way to Disable Beagle Completely During Installation openSUSE-11.2: Evaluation Priority Requester: Important Requested by: JP Rosevear (jproseve) Partner organization: openSUSE.org Description: We need to either have beagle off by default and allow a user to enable it the first time they search or provide an install option to turn it off. Relations: - Better Beagle Acceptance (feature/id: 303367) - Easy way to disable beagle completely during install (novell/bugzilla/id: 282678) https://bugzilla.novell.com/show_bug.cgi?id=282678 Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:52:46) I prefer to start with disabled, offer option to run at first search. We are proliferating checkboxes in the installer too much. + #2: Kevin Dupuy (kdupuy9) (2009-01-29 23:40:17) + I prefer a more sane option than disabling it by default... instead, + allow the user to go in and uninstall it from the installation software + screen, just as they would any other app (perhaps make 'Desktop Search' + pattern, installed by default?) We just need to insure that + uninstalling Beagle doesn't throw up any dependency errors. -- openSUSE Feature: https://features.opensuse.org/305296

1 0

[openFATE 120326] Resume download
by fate_noreply＠suse.de 29 Jan '09

29 Jan '09

Feature changed by: Misbachul Munir (m_goku) Feature #120326, revision 46 Title: Resume download openSUSE-10.2: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2006-09-21 09:56:17 reject reason: Not enough resources to implement in time. Priority Requester: Desirable Projectmanager: Desirable openSUSE-10.3: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2007-07-25 15:20:32 reject reason: Out of time. Postponing. Priority Requester: Desirable Projectmanager: Desirable openSUSE-11.0: Rejected by Jiri Srain <jsrain(a)novell.com> reject date: 2008-03-28 13:51:03 reject reason: Out of resources for 11.0. Priority Requester: Desirable Projectmanager: Important openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-07-01 11:34:46 reject reason: Postponing, needs downloading refactor. Priority Requester: Desirable openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Klaus Kämpf (kwk) Partner organization: openSUSE.org Description: YaST/YOU times out too easy when downloading large packages like kde- base (14 MB) over a single ISDN connection. Please cache the half downloaded package so I don't have to start from the beginning again. See http://bugzilla.suse.de/show_bug.cgi?id=9740 (http://bugzilla.suse.de/show_bug.cgi?id=9740) http://bugzilla.suse.de/show_bug.cgi?id=278507 (http://bugzilla.suse.de/show_bug.cgi?id=9740) Discussion: #1: Gerald Pfeifer (geraldpfeifer) (2006-06-30 17:40:31) Klaus, do you now whether this is still an issue? #2: Klaus Kämpf (kwk) (2006-06-30 18:38:23) We still have very large packages (kernel, OpenOffice_org) which might not download completely in one go. #7: Stanislav Visnovsky (visnov) (2007-11-23 10:32:46) Related to commit-refactoring. #9: Federico Lucifredi (flucifredi) (2008-06-12 20:21:33) Klaus, are you still running ISDN? just kidding :-) Stano, please your opinion on workload - is this easily achievable? if not, there are hgher priorities. #10: Stanislav Visnovsky (visnov) (2008-06-20 13:10:21) (reply to #9) Jiri, could we get estimate for this? #11: Jiri Srain (jsrain) (2008-08-04 08:59:34) (reply to #10) Since curl itself does support resuming download, then this feature should not be hard to be implemented. #12: Ruchir Brahmbhatt (ruchir) (2009-01-17 12:07:25) I also vote for this feature. - #13: Dmitri Mittov (michael_knight) (2009-01-19 09:01:09) + #13: Dmitry Mittov (michael_knight) (2009-01-19 09:01:09) It is also a great problem when you use slow mirror. download.opensuse. org redirects me to one of yandex mirrors (score 20). And I have timeout on big packages. #14: Piotrek Juzwiak (benderbendingrodriguez) (2009-01-21 18:17:13) I'd vote at least for a way to change the timeout settings for YaST or it doesn't solve the problem? #15: Alam Aby Bashit (init7) (2009-01-22 09:35:17) I'd like to vote this feature implemented in 11.2. You surely want to have resume capability if you have unreliable yet slow internet connection for say, updating KDE 4.2 :) #16: Duncan Mac-Vicar (dmacvicar) (2009-01-22 15:14:44) (reply to #15) Please stop this "I vote for this" or "+1" or "mee too" comments. There is no voting system in FATE yet, but following a discussion about "I want this too" makes hard to evaluate features. #17: James Mason (bear454) (2009-01-24 06:05:01) Could this be accomplished using a bittorrent backend instead of curl ? -- openSUSE Feature: https://features.opensuse.org/120326

1 0

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

29 Jan '09

Feature changed by: Duncan Mac-Vicar (dmacvicar) Feature #305634, revision 38 Title: Debian-like dist-upgrade live system full version upgrade openSUSE-11.2: Evaluation Priority Requester: Mandatory 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. #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. -- openSUSE Feature: https://features.opensuse.org/305634

1 0

[openFATE 303749] provide common source for a overall battery time information
by fate_noreply＠suse.de 29 Jan '09

29 Jan '09

Feature changed by: Michael Loeffler (sprudel24) Feature #303749, revision 18 Title: provide common source for a overall battery time information openSUSE-11.1: Rejected by Christian Zoz <zoz(a)novell.com> reject date: 2008-09-12 12:04:06 reject reason: We could not provide that in time. And it does not effect UI funtionality. Priority Requester: Important Projectmanager: Desirable - openSUSE-11.2: New + openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Danny Kukawka (dkukawka) Partner organization: openSUSE.org Description: In the past we used powersaved to get battery information. Powersaved provided information about each battery but also about all batteries. There was a overall battery object which e.g. provided remaining time information for all batteries in the system (of one type). Now we use HAL to collect these information. Unfortunately there is no such overall battery object to calculate the full remaining time in multibattery machines. HAL has no such object like powersaved. AFAIK g-p-m calculates it own remaining time, but KPowersave only use the info from HAL. Because of this KPowersave show no overall remaining time. IMO it's no option to do all the magic like g-p-m in KPowersave. There should be a common place to do this and provide the same information for all applications (KDE/GNOME/....). It could be HAL or a new powermanagement daemon (like powersaved) if DeviceKit is comming. Relations: - Power consumption gauge (feature/id: 302446) - Support multiple battery indication (feature/id: 304716) Discussion: #1: Christian Zoz (zoz) (2008-06-19 14:46:22) This feature is usefull if all applications that show battery information would use it. Jared, who can tell us if g-p-m would accept that solution? - We should also enhance this feature a bit. Hal should also serve individual and overall power consumption. This is needed for feature: #302446: Power consumption gauge #3: Jared Allen (jpallen) (2008-06-19 09:29:23) (reply to #1) We need to make sure that any changes are made in time for g-p-m to take advantage of the changes in time for SLE11. Richard Hughes is the upstream maintainer. #2: Christian Zoz (zoz) (2008-06-19 15:01:35) I forgot to mention another feature that should make use of this: #304716: Support multiple battery indication #4: Christian Zoz (zoz) (2008-06-25 19:07:40) Danny, please contact Richard. Since you need that feature for kpowersave anyway, let's do it. #5: JP Rosevear (jproseve) (2008-09-11 19:36:06) I assume we are going to reject this? -- openSUSE Feature: https://features.opensuse.org/303749

1 0

[openFATE 305715] Package event framework
by fate_noreply＠suse.de 29 Jan '09

29 Jan '09

Feature changed by: Klaus Kämpf (kwk) Feature #305715, revision 11 Title: Package event framework openSUSE-11.2: New Priority Requester: Desirable Requested by: Andreas Gruenbacher (agruen) Partner organization: openSUSE.org Description: The installation, upgrade, or removal of several packages triggers actions such as running ldconfig, rebuilding the initrd, or similar. Those actions are not specific to the package at hand, but either global with a system-wide effect (such as running ldconfig), or they affect a group of packages (such as all kernel (sub-)packages of a specific version, including all KMPs affecting it). Those actions need to be run eventually (with order restrictions relative to other package installs, upgrades, or removals), but running them again and again for each package is wasteful. (Example: with the kernel packages split into kernel-$flavor-base, kernel-$flavor, and kernel-$flavor-extra in CODE11, we currently run mkinitrd out of the %post script of each package. We don't know which of those packages will be installed, and when generating the initrd is supposed to succeed. This both wastes time, and we also cannot tell transient from permanent failures.) In former days, SuSEconfig was used for some of those tasks, but it turned into a major nightmare (perhaps due to its design). It would be nice if we could come up with a framework in which packages can trigger events and define which actions they need to be run, and rpm will then perform those actions in an appropriate order, avoiding repeating the same action unnecessarily. (The dependencies between actions and package installs/upgrades/removals are somewhat complex, but I think they are manageable.) Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-23 18:09:34) This is desirable only as it happens within RPM's framework (or if the additions are "candy" that does not affect the actual result). This includes upstreaming. I do not want to comment besides the RPM requirement until Engineering determines how (and if) to proceed. There are too many factors involved. Stano, Needinfo me back when you guys have a settled position or decide to postpone this one given the other priorities. #2: Klaus Kämpf (kwk) (2009-01-29 12:45:22) Actually, there is probably litte engineering can do or decide here imho. It very much depends on PMs long-term strategy for RPM. There are currently two options * One is to stay with rpm 4.x and keep the status quo. * The other is to move up to rpm5 and try to influence its development. Upstream implementation of the feature request can only happen within rpm5. Adopting rpm5 for the distribution has several prerequisites: * Investment into rpm5 development. * Getting more distributions to adopt rpm5. * Influencing Linux Standards Base to accept rpm5. Given recent comments from RedHat/Fedora, widespread rpm5 adoption looks rather unlikely. #3: Michael Schröder (mlschroe) (2009-01-29 12:50:19) (reply to #2) That sounds like rpm-4 doesn't get new features at all, which is simply not true. Actually I think it's probably easier to get new features into rpm-4, because it's very hard to convince Jeff of something he doesn't like, whereas Panu is more open. + #4: Klaus Kämpf (kwk) (2009-01-29 13:22:30) (reply to #3) + Now thats good to know. + But this probably still needs a significant investment (and a fair bit + of persuasion) into rpm4, I guess. -- openSUSE Feature: https://features.opensuse.org/305715

1 0

[openFATE 305715] Package event framework
by fate_noreply＠suse.de 29 Jan '09

29 Jan '09

Feature changed by: Andreas Gruenbacher (agruen) Feature #305715, revision 10 Title: Package event framework openSUSE-11.2: New Priority Requester: Desirable Requested by: Andreas Gruenbacher (agruen) Partner organization: openSUSE.org Description: The installation, upgrade, or removal of several packages triggers actions such as running ldconfig, rebuilding the initrd, or similar. Those actions are not specific to the package at hand, but either global with a system-wide effect (such as running ldconfig), or they affect a group of packages (such as all kernel (sub-)packages of a specific version, including all KMPs affecting it). Those actions need to be run eventually (with order restrictions relative to other package installs, upgrades, or removals), but running them again and again for each package is wasteful. (Example: with the kernel packages split into kernel-$flavor-base, kernel-$flavor, and kernel-$flavor-extra in CODE11, we currently run - mkinitrd in the %post script of each package. We don't know which of - those packages will be installed, and when generating the initrd is + mkinitrd out of the %post script of each package. We don't know which + of those packages will be installed, and when generating the initrd is supposed to succeed. This both wastes time, and we also cannot tell transient from permanent failures.) In former days, SuSEconfig was used for some of those tasks, but it turned into a major nightmare (perhaps due to its design). It would be nice if we could come up with a framework in which packages can trigger events and define which actions they need to be run, and rpm will then perform those actions in an appropriate order, avoiding repeating the same action unnecessarily. (The dependencies between actions and package installs/upgrades/removals are somewhat complex, but I think they are manageable.) Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-23 18:09:34) This is desirable only as it happens within RPM's framework (or if the additions are "candy" that does not affect the actual result). This includes upstreaming. I do not want to comment besides the RPM requirement until Engineering determines how (and if) to proceed. There are too many factors involved. Stano, Needinfo me back when you guys have a settled position or decide to postpone this one given the other priorities. #2: Klaus Kämpf (kwk) (2009-01-29 12:45:22) Actually, there is probably litte engineering can do or decide here imho. It very much depends on PMs long-term strategy for RPM. There are currently two options * One is to stay with rpm 4.x and keep the status quo. * The other is to move up to rpm5 and try to influence its development. Upstream implementation of the feature request can only happen within rpm5. Adopting rpm5 for the distribution has several prerequisites: * Investment into rpm5 development. * Getting more distributions to adopt rpm5. * Influencing Linux Standards Base to accept rpm5. Given recent comments from RedHat/Fedora, widespread rpm5 adoption looks rather unlikely. #3: Michael Schröder (mlschroe) (2009-01-29 12:50:19) (reply to #2) That sounds like rpm-4 doesn't get new features at all, which is simply not true. Actually I think it's probably easier to get new features into rpm-4, because it's very hard to convince Jeff of something he doesn't like, whereas Panu is more open. -- openSUSE Feature: https://features.opensuse.org/305715

1 0

[openFATE 305715] Package event framework
by fate_noreply＠suse.de 29 Jan '09

29 Jan '09

Feature changed by: Andreas Gruenbacher (agruen) Feature #305715, revision 9 Title: Package event framework openSUSE-11.2: New Priority Requester: Desirable Requested by: Andreas Gruenbacher (agruen) Partner organization: openSUSE.org Description: The installation, upgrade, or removal of several packages triggers actions such as running ldconfig, rebuilding the initrd, or similar. Those actions are not specific to the package at hand, but either global with a system-wide effect (such as running ldconfig), or they affect a group of packages (such as all kernel (sub-)packages of a - specific version, including all KMPs affectiong it). Those actions need + specific version, including all KMPs affecting it). Those actions need to be run eventually (with order restrictions relative to other package installs, upgrades, or removals), but running them again and again for each package is wasteful. + (Example: with the kernel packages split into kernel-$flavor-base, + kernel-$flavor, and kernel-$flavor-extra in CODE11, we currently run + mkinitrd in the %post script of each package. We don't know which of + those packages will be installed, and when generating the initrd is + supposed to succeed. This both wastes time, and we also cannot tell + transient from permanent failures.) In former days, SuSEconfig was used for some of those tasks, but it turned into a major nightmare (perhaps due to its design). It would be nice if we could come up with a framework in which packages can trigger events and define which actions they need to be run, and rpm will then perform those actions in an appropriate order, avoiding repeating the same action unnecessarily. (The dependencies between actions and package installs/upgrades/removals are somewhat complex, but I think they are manageable.) Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-23 18:09:34) This is desirable only as it happens within RPM's framework (or if the additions are "candy" that does not affect the actual result). This includes upstreaming. I do not want to comment besides the RPM requirement until Engineering determines how (and if) to proceed. There are too many factors involved. Stano, Needinfo me back when you guys have a settled position or decide to postpone this one given the other priorities. #2: Klaus Kämpf (kwk) (2009-01-29 12:45:22) Actually, there is probably litte engineering can do or decide here imho. It very much depends on PMs long-term strategy for RPM. There are currently two options * One is to stay with rpm 4.x and keep the status quo. * The other is to move up to rpm5 and try to influence its development. Upstream implementation of the feature request can only happen within rpm5. Adopting rpm5 for the distribution has several prerequisites: * Investment into rpm5 development. * Getting more distributions to adopt rpm5. * Influencing Linux Standards Base to accept rpm5. Given recent comments from RedHat/Fedora, widespread rpm5 adoption looks rather unlikely. #3: Michael Schröder (mlschroe) (2009-01-29 12:50:19) (reply to #2) That sounds like rpm-4 doesn't get new features at all, which is simply not true. Actually I think it's probably easier to get new features into rpm-4, because it's very hard to convince Jeff of something he doesn't like, whereas Panu is more open. -- openSUSE Feature: https://features.opensuse.org/305715

1 0

[openFATE 303749] provide common source for a overall battery time information
by fate_noreply＠suse.de 29 Jan '09

29 Jan '09

Feature changed by: Michael Loeffler (sprudel24) Feature #303749, revision 17 Title: provide common source for a overall battery time information openSUSE-11.1: Rejected by Christian Zoz <zoz(a)novell.com> reject date: 2008-09-12 12:04:06 reject reason: We could not provide that in time. And it does not effect UI funtionality. Priority Requester: Important Projectmanager: Desirable openSUSE-11.2: New Priority Requester: Important Requested by: Danny Kukawka (dkukawka) + Partner organization: openSUSE.org Description: In the past we used powersaved to get battery information. Powersaved provided information about each battery but also about all batteries. There was a overall battery object which e.g. provided remaining time information for all batteries in the system (of one type). Now we use HAL to collect these information. Unfortunately there is no such overall battery object to calculate the full remaining time in multibattery machines. HAL has no such object like powersaved. AFAIK g-p-m calculates it own remaining time, but KPowersave only use the info from HAL. Because of this KPowersave show no overall remaining time. IMO it's no option to do all the magic like g-p-m in KPowersave. There should be a common place to do this and provide the same information for all applications (KDE/GNOME/....). It could be HAL or a new powermanagement daemon (like powersaved) if DeviceKit is comming. Relations: - Power consumption gauge (feature/id: 302446) - Support multiple battery indication (feature/id: 304716) Discussion: #1: Christian Zoz (zoz) (2008-06-19 14:46:22) This feature is usefull if all applications that show battery information would use it. Jared, who can tell us if g-p-m would accept that solution? - We should also enhance this feature a bit. Hal should also serve individual and overall power consumption. This is needed for feature: #302446: Power consumption gauge #3: Jared Allen (jpallen) (2008-06-19 09:29:23) (reply to #1) We need to make sure that any changes are made in time for g-p-m to take advantage of the changes in time for SLE11. Richard Hughes is the upstream maintainer. #2: Christian Zoz (zoz) (2008-06-19 15:01:35) I forgot to mention another feature that should make use of this: #304716: Support multiple battery indication #4: Christian Zoz (zoz) (2008-06-25 19:07:40) Danny, please contact Richard. Since you need that feature for kpowersave anyway, let's do it. #5: JP Rosevear (jproseve) (2008-09-11 19:36:06) I assume we are going to reject this? -- openSUSE Feature: https://features.opensuse.org/303749

1 0