- openSUSE Features

[openFate 120340] Run download and install in parallel
by fate_noreply＠suse.de 06 Jan '09

06 Jan '09

Feature changed by: Stanislav Visnovsky <visnov(a)novell.com> Feature #120340, revision 38 Title: Run download and install in parallel openSUSE-10.2: Rejected by Klaus Kämpf <kkaempf(a)novell.com> reject date: 2006-08-09 11:36:10 reject reason: Not possible in 10.2 timeframe openSUSE-10.3: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2007-08-01 10:25:01 reject reason: Out of time. openSUSE-11.0: Rejected by Jiri Srain <jsrain(a)novell.com> reject date: 2008-03-28 13:56:11 reject reason: Out of resources for 11.0. openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-07-11 12:06:35 reject reason: This needs to wait. Postponing. openSUSE-11.2: New SLED-11-SP1 SLES-11 SLES-11-SP1 Requested by: Klaus Kämpf (kwk) Requested by: Peter Poeml (poeml) Requested by: Reinhard Max (rmax) Interested: Ján Kupec (jkupec) Interested: Lukas Ocilka (locilka) Interested: Stephan Binner (beineri) + Partner organization: openSUSE.org Description: Network installation could be improved by running package download and package installation in parallel. References: https://bugzilla.novell.com/show_bug.cgi?id=60844 https://bugzilla.novell.com/show_bug.cgi?id=209799 https://bugzilla.novell.com/show_bug.cgi?id=128050 https://bugzilla.novell.com/show_bug.cgi?id=370457 https://bugzilla.novell.com/show_bug.cgi?id=370054 https://bugzilla.novell.com/show_bug.cgi?id=385711 http://en.opensuse.org/Libzypp/Failover http://metalinker.org/ Fate #300660: Download package groups before install Discussion: #2: Klaus Kämpf (kwk) (2006-08-09 11:36:42) Michael already looked at this. Should be further evaluated for 10.3 #3: Edith Parzefall (emapedl) (2007-07-31 16:56:12) Problem is: what do we do if we lost the network connection when only half the packages are installed? #7: Reinhard Max (rmax) (2008-04-10 11:42:43) (reply to #3) I think this is a general problem for network based installations. Can you elaborate if/why you see this as a special problem when download and installation are running in parallel? #8: Peter Poeml (poeml) (2008-05-19 14:49:53) (reply to #7) For reliable operation of a business critical server, it is a must that packages are downloaded first, before the installation/update is started. Otherwise a network outage can lead to a broken system which is half updated. So if parallel download/install is implemented (for desktop users, maybe...) then please make sure that it is possible to disable it. #9: Reinhard Max (rmax) (2008-05-19 16:01:15) (reply to #8) As we just sorted out on IRC, the current implementation also doesn't allow to complete download before starting installation and the feature proposed here wouldn't make this worse. But as the wish of server admins to have all packages downloaded before starting to install them is very valid, I think we should extend this feature request to contain that requirement as well, and probably rename it to "decouple download and installation". If download and installation are properly decoupled, it should just be a matter of the parameters the algorithm is called with to get one of the following behaviours: * Download and install packages one by one (as it is now) * Keep downloading subsequent packages while installing (as originally proposed here) * Use a fixed-size download cache for flow control between download an installations (in situations where download is faster than installation and disk space is limited) * Download all packages of an update or installation and install them afterwards (as requested by Peter for server admins) #10: Jiri Srain (jsrain) (2008-05-20 10:22:10) (reply to #9) We already do have similar feature: #300660: Download package groups before install #4: Edith Parzefall (emapedl) (2007-07-31 16:57:22) Please reject for 10.3. #5: Duncan Mac-Vicar (dmacvicar) (2008-01-10 16:23:46) This is included in the ZYpp plan for 11.0, however implementation will start after beta. Will keep in evaluation, it depends on other milestones for beta1 -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=120340

1 0

[openFate 304879] OOo: Update of KDE integration to KDE4
by fate_noreply＠suse.de 06 Jan '09

06 Jan '09

Feature changed by: Stephan Binner <stbinner(a)novell.com> Feature #304879, revision 15 Title: OOo: Update of KDE integration to KDE4 openSUSE-11.1: Rejected by JP Rosevear <jpr(a)novell.com> reject date: 2008-08-15 11:47:35 reject reason: As per PM recommendation. SLED-11 SLED-11-SP1 Requested by: Stephan Binner (beineri) Interested: Stephan Kulow (coolo) + Partner organization: openSUSE.org Description: The current OOo KDE integration (file dialogs, addressbook, interface/icon theme,...) is based on KDE3. As openSUSE 11.1/SLED 11 will likely not include KDE3 anymore it has to be upgraded to KDE4. Discussion: #1: Stephan Kulow (coolo) (2008-06-13 09:54:23) There are far too many mandatory OOo features. Please reevaluate - it's unlikely that we won't ship KDE3 apps in SLED11 #2: Dirk Mueller (dirkmueller) (2008-06-13 13:25:48) (reply to #1) we will ship KDE3 libs, yes. that doesn't mean that we desire to have KDE3 app dependencies ;) -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=304879

1 0

[openFate 300758] Show orphaned packages
by fate_noreply＠suse.de 06 Jan '09

06 Jan '09

Feature changed by: Ján Kupec <jkupec(a)novell.com> Feature #300758, revision 34 Title: Show orphaned packages openSUSE-10.2: Rejected by Thorsten Kukuk <kukuk(a)novell.com> reject date: 2006-08-02 11:31:19 reject reason: For SL10.2 we have to get libzypp really stable and fast before we add new features. openSUSE-10.3: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2007-07-17 17:03:57 reject reason: Postponing. openSUSE-11.0: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2007-11-21 12:16:20 reject reason: Out of scope for 11.0 openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-07-07 13:34:02 reject reason: Postponing, needs underlaying infrastructure to be fixed first. openSUSE-11.2: New SLED-11 SLED-11-SP1 SLES-11 SLES-11-SP1 Requested by: Stephan Binner (beineri) Interested: Andreas Jaeger (a_jaeger) + Interested: Ján Kupec (jkupec) Interested: Matthias Eckermann (mge1512) Interested: Vincent Untz (vuntz) + Partner organization: openSUSE.org Description: The package manager should learn to show orphanized packages (packages which are not required by other packages and are not in wanted selections) and allow to deinstall them like the popular debfoster/deborphan tools. A typical use case: user installs an application which pulls in some dependencies to test it, uninstalls the application shortly after or way later but the dependencies stay unused installed on the system. Commandline UI (zypper) only. References: https://bugzilla.novell.com/show_bug.cgi?id=166132 Discussion: #1: Jiri Srain (jsrain) (2007-06-05 13:46:00) Schubi, is there any possibility to make solver tell which packages are orphanized? It would be interesting especially if the packages which are marked for deletion were considered as non-installed (eg. if foo- devel is installed but marked for deletion and nothing else requires foo, then foo is orphanized). #2: Stefan Schubert (schubi2) (2007-06-06 11:04:04) (reply to #1) Currently not cause the solver has no information about who (user, package,...) has triggered the installation of a package. If we are storing this information it would be possible for solver to remove these kind of packages too. It is not simple but doable. By the way, we will have to store this kind of information in the future. E.g. we need to save the "keep state by user" in a database in order to regard this state in future solver runs. #3: Jiri Srain (jsrain) (2007-06-06 14:25:07) (reply to #2) Looks like a missunderstanding. Basically every package wihch is not required/recommended/suggested or doesn't enhance anything that is installed and not marked for deletion is IMO considered to be orphanized. If user eg. wants to remove a pattern including all its packages (which are not required by something else), solver providing this kind of information would help a lot (and I don't think that we would need any other information to be stored. #4: Stefan Schubert (schubi2) (2007-06-06 15:33:44) (reply to #3) I do not think so. What does "orphanized" mean ? Let me take your example from comment #1. foo should be deleted too if the user delete foo-devel and foo has been installed due the requirement of foo-devel. BUT the user will kill us if we are deleting foo although the user has installed foo explicit sometime ago in a seperate installation workflow. So this information ( The USER has installed foo) will be currently not saved and is needed here to decide if foo has to be deleted or not. #5: Stefan Schubert (schubi2) (2007-06-06 15:39:47) (reply to #3) Lets take your example concerning the erasing of patterns. That is much more complex. I have already described the problem here: http://en.opensuse.org/Libzypp/Solver#Known_Problems " Proper behaviour of erasing patterns" There are already some bugzilla entries: Bug 274283 - Delete iFolder from YaST makes eDirectory Delete mandatory Bug 238250 - YaST does not upgrade an Add-on Product #6: Jiri Srain (jsrain) (2007-06-08 16:46:32) See also https://bugzilla.novell.com/show_bug.cgi?id=166132 This is another use case for the same solver functionality #8: Federico Lucifredi (flucifredi) (2008-06-12 20:46:17) this should be commandline-only, definitely an advanced-user option. #9: Federico Lucifredi (flucifredi) (2008-06-12 20:47:28) cut from description: See Bug 140346 #10: Duncan Mac-Vicar (dmacvicar) (2008-11-03 11:24:53) As discussed in Prague, this could be done using the package history once we have a reader. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=300758

1 0

[openFate 302921] Testing openSUSE Feature Tracking
by fate_noreply＠suse.de 05 Jan '09

05 Jan '09

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

1 0

[openFate 303532] Reduce size of updates for openSUSE Factory
by fate_noreply＠suse.de 03 Jan '09

03 Jan '09

Feature changed by: Gerald Pfeifer <gp(a)novell.com> Feature #303532, revision 14 Title: Reduce size of updates for openSUSE Factory Buildservice: Evaluation Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Stephan Kulow <coolo(a)novell.com> reject date: 2008-06-06 09:06:29 reject reason: not really attached to a specific openSUSE version Priority Requester: Important Projectmanager: Important openSUSE-11.1: Rejected by Adrian Schröter <adrian(a)novell.com> reject date: 2008-11-06 16:10:03 reject reason: This is a build service feature, but no distribution feature. Priority Requester: Important Projectmanager: Important Requested by: Michael Loeffler <michl(a)novell.com> + Partner organization: openSUSE.org Description: Each update currently is around 2GB which is already much for broadband bandwith. For user with less bandwith it's by and large impossible to use Factory. Goal is to reduce size of updates and stay with frequent updates to offer latest software to the user. As we want more people using Factory it's usage needs to be conveniant. Discussion: #1: Stephan Kulow <coolo(a)novell.com> (2008-03-27 16:48:43) According to discussions with Rudi and mls, the delta setup on dist need to be changed to also contain the rpm header and the deltas need to be indexed in a way that zypp will see them. So we can still use drpmsync for internal distribution and put the deltas only in instsource for mirrors. #2: Duncan Mac-Vicar <dmacvicar(a)novell.com> (2008-04-22 13:28:56) This will happen automatically once the remaining parts of libzypp deltarpm handling are finished. We only need to agree on the format. I will propose something today. #3: Duncan Mac-Vicar <dmacvicar(a)novell.com> (2008-05-26 17:09:31) ZYpp side is done. The only thing that needs to be done is to generate the deltarpm metadata in factory. I will post link to documentation and examples shortly. + #4: Gerald Pfeifer <gp(a)novell.com> (2009-01-03 14:54:00) + Opening this up for openSUSE.org. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=303532

1 0

[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