Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Requirements Council Update Manager Issue"

(Issue)
 
(One intermediate revision by one other user not shown)
Line 1: Line 1:
 
[[Requirements_Council_Issue_Tracking|(Back to main Issues Page)]]
 
[[Requirements_Council_Issue_Tracking|(Back to main Issues Page)]]
<pre> Please feel free to edit this page directly - in the spirit of WIKI.  If you wish to ask questions or are uncomfortable making changes, feel free to use the pre tags </pre>
+
<pre>
 +
Please feel free to edit this page directly - in the spirit of
 +
WIKI.  If you wish to ask questions or are uncomfortable  
 +
making changes, feel free to comment within pre tags
 +
like this note is.</pre>
 
== Meetings About the Issue ==
 
== Meetings About the Issue ==
 
===December 7th Teleconference===
 
===December 7th Teleconference===
Line 43: Line 47:
  
 
* Other references
 
* Other references
 +
 +
 +
----
 +
 +
Nokia input:
 +
* What is the problem:
 +
While a very valuable tool, we feel that update manager is not all that it could be. Nokia would like to see improvements in Update manager in the following area:
 +
*Proposal for discussion
 +
** Proactively informing the Eclipse user about the availability of relevant updates. The Update manager could be used both to ensure maximal user benefit from a product as well as for pro-active marketing of new features and versions.
 +
*** In a proactive model, there would be a reverse channel from the update site to the developer about updates to those products/plugins that the developer has taken into use. The reverse channel could be based on existing technologies such as RSS feeds. Once a user has received information about the availability of new updates, it should take just one click to initiate the update. However the idea is that the user shall still be in control of the update, updates should not be applied automatically.
 +
*** To avoid spamming the user with update information, there needs to be a simple way for the user to "register" for updates. Typically installation of a plug-in could automatically create such a "registration" but other registration modes might be needed.
 +
*** A pro-active update manager could also become a marketing and sales channel for developers selling commercial Eclipse products. This would require that the Update manager would have notions for various types of updates: some updates are maintenance and would be covered by and existing license or agreement. In other cases, an update will require the user to purchase a new version of a product. In many cases these two update modes should be handled in different ways: A user with version N.M of product, should be offered versions N.(M+1) as an update but version (N+1).1 only after a sales event. Perhaps the update manager could even provide hooks for an e-sales event? In any case, the user of version N.M should not be offered the (N+1) maintenance versions prior to purchase so version (N+1).2 should not be presented as an update option to the user on N.M.
 +
*** With permissions the reverse channel could also provide information about closely related products. In the mobile domain, a key component of the development is an SDK with the device emulator and other device specific content. While technically separate (non-Eclipse) products, providing information about new SDKs would a a typical example of how being able to provide information about "adjacent" products would create value.
 +
*** Management back-end for update manager to allow product classification and definiting relations between products etc.
 +
 +
* Author of Issue:
 +
Håkan Mitts
  
 
==Action Plan and Status==
 
==Action Plan and Status==
 
* Until early Jan, members are to have their staff provide details on the issue.
 
* Until early Jan, members are to have their staff provide details on the issue.

Latest revision as of 06:20, 16 January 2007

(Back to main Issues Page)

Please feel free to edit this page directly - in the spirit of
WIKI.  If you wish to ask questions or are uncomfortable 
making changes, feel free to comment within pre tags
like this note is.

Meetings About the Issue

December 7th Teleconference

Attendees:

  • Haakan Mitts, Nokia
  • Donald Smith, Eclipse Foundation
  • Stephen Henderson, Borland
  • Anurag Gupta, Intel
  • Paul Styles, Compuware
  • Yossi Leon, Zend

Notes:

  • This meeting laid the outline of the issue. Call to action from participants on call to get more specific information from their organizations.

Issue

Be it resolved that the Requirements Council would like to drive resolution on some of the feature functionality of the Eclipse Update Manager.

  • What is the problem:
    • Update manager does not really support non-Eclipse things such as making a database update, file
      • Possible to request wire of binary but misses dependency Checking
    • Main issue is distributing non-Eclipse products
  • Please explain why there are no ways to easily work around the issues listed above.
  • Author of Issue:
    • Initial contribution is attendees of December 7th teleconference
  • Supporting the case (list of RC members and background):
    • PLEASE ADD YOUR NAME/CONTACT INFO HERE IF YOU UPDATE THIS PAGE.
  • Persons/Projects of interest
    • PLEASE LIST PEOPLE WE SHOULD CONTACT OR KNOW ABOUT HERE
  • Relation to a theme
  • Traceability
  • List of Bug reports
    • PLEASE LIST LINKS TO BUG REPORTS, IF ANY, HERE
  • List of mail list pointers
    • PLEASE LIST LINKS TO MAIL LIST POSTS HERE
  • Other references



Nokia input:

  • What is the problem:

While a very valuable tool, we feel that update manager is not all that it could be. Nokia would like to see improvements in Update manager in the following area:

  • Proposal for discussion
    • Proactively informing the Eclipse user about the availability of relevant updates. The Update manager could be used both to ensure maximal user benefit from a product as well as for pro-active marketing of new features and versions.
      • In a proactive model, there would be a reverse channel from the update site to the developer about updates to those products/plugins that the developer has taken into use. The reverse channel could be based on existing technologies such as RSS feeds. Once a user has received information about the availability of new updates, it should take just one click to initiate the update. However the idea is that the user shall still be in control of the update, updates should not be applied automatically.
      • To avoid spamming the user with update information, there needs to be a simple way for the user to "register" for updates. Typically installation of a plug-in could automatically create such a "registration" but other registration modes might be needed.
      • A pro-active update manager could also become a marketing and sales channel for developers selling commercial Eclipse products. This would require that the Update manager would have notions for various types of updates: some updates are maintenance and would be covered by and existing license or agreement. In other cases, an update will require the user to purchase a new version of a product. In many cases these two update modes should be handled in different ways: A user with version N.M of product, should be offered versions N.(M+1) as an update but version (N+1).1 only after a sales event. Perhaps the update manager could even provide hooks for an e-sales event? In any case, the user of version N.M should not be offered the (N+1) maintenance versions prior to purchase so version (N+1).2 should not be presented as an update option to the user on N.M.
      • With permissions the reverse channel could also provide information about closely related products. In the mobile domain, a key component of the development is an SDK with the device emulator and other device specific content. While technically separate (non-Eclipse) products, providing information about new SDKs would a a typical example of how being able to provide information about "adjacent" products would create value.
      • Management back-end for update manager to allow product classification and definiting relations between products etc.
  • Author of Issue:

Håkan Mitts

Action Plan and Status

  • Until early Jan, members are to have their staff provide details on the issue.

Back to the top