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.
Difference between revisions of "Polarsys/UseCases"
< Polarsys
(→Bug fix) |
|||
| Line 1: | Line 1: | ||
| − | =Support | + | =Support= |
| + | How to ensure that a bug is fixed in a timely fashion, given that the Polarsys WG does not have enough ressources to provide such services ?<br> | ||
| − | + | A solution could be the following: | |
| − | + | * Users that want professional support subscribe to a professional services offer provided by a Branded Polarsys Provider, which could include: | |
| − | + | ** Advice, explanations regarding the use of the tools; | |
| + | ** Bug fixes; | ||
| + | * In order to distinguish from the Polarsys WG and therefore be able to have a sustainable business model, Branded Polarsys Providers must offer additional added value, which could be : | ||
| + | ** the provision of validated binaries that are not provided by the Polarsys WG, and | ||
| + | ** the provision of customer-specific releases when there is an urgent and important bug to be fixed; | ||
| + | * To provide for VLTS, support contracts should include the following best practices: | ||
| + | ** All patches should be given back to the Polarsys LTS branch, | ||
| + | ** unless there is a good technical or confidentiality reason provided. | ||
| + | * The Polarsys WG would provide to its members a demo version only to avoid competing with Branded providers. | ||
| − | # | + | Open questions: |
| − | # | + | # Support Contracts are accessible only to Polarsys members ? |
| − | + | # who controls the Polarsys VLTS branch ? | |
| − | + | # What if there is no Branded provider in a given area ? | |
| − | + | ||
| − | + | ||
| − | + | ||
=Feature Request= | =Feature Request= | ||
| + | Feature requests should be treated the same way: | ||
| + | |||
| + | * When someone needs a new feature, he does it as part of a contract with a Branded Polarsys provider; | ||
| + | * The development should be given back to the Polarsys LTS branch, unless there is a good technical not to do so; this way, users are sure not to pay two times for the same feature; | ||
| + | |||
| + | Open questions: | ||
| + | * Is it possible to find a system that allow users sharing the development costs ? | ||
| + | ** If we use a system based on good will, we are likely to end up in a situation where urgent needs are funded by individual users, no matter the Polarsys roadmap, and non-urgent needs will remain unfunded forever; | ||
| + | ** A mandatory system is likely not to be approved. | ||
=Configuration Management is a transverse issue to Bug Fix and Feature Requests= | =Configuration Management is a transverse issue to Bug Fix and Feature Requests= | ||
| − | + | Too many versions tends towards a custom development model and lowers economy of scale. In order to save money and allow affordable support, we need to tend to COTS. | |
Revision as of 12:09, 5 April 2012
Support
How to ensure that a bug is fixed in a timely fashion, given that the Polarsys WG does not have enough ressources to provide such services ?
A solution could be the following:
- Users that want professional support subscribe to a professional services offer provided by a Branded Polarsys Provider, which could include:
- Advice, explanations regarding the use of the tools;
- Bug fixes;
- In order to distinguish from the Polarsys WG and therefore be able to have a sustainable business model, Branded Polarsys Providers must offer additional added value, which could be :
- the provision of validated binaries that are not provided by the Polarsys WG, and
- the provision of customer-specific releases when there is an urgent and important bug to be fixed;
- To provide for VLTS, support contracts should include the following best practices:
- All patches should be given back to the Polarsys LTS branch,
- unless there is a good technical or confidentiality reason provided.
- The Polarsys WG would provide to its members a demo version only to avoid competing with Branded providers.
Open questions:
- Support Contracts are accessible only to Polarsys members ?
- who controls the Polarsys VLTS branch ?
- What if there is no Branded provider in a given area ?
Feature Request
Feature requests should be treated the same way:
- When someone needs a new feature, he does it as part of a contract with a Branded Polarsys provider;
- The development should be given back to the Polarsys LTS branch, unless there is a good technical not to do so; this way, users are sure not to pay two times for the same feature;
Open questions:
- Is it possible to find a system that allow users sharing the development costs ?
- If we use a system based on good will, we are likely to end up in a situation where urgent needs are funded by individual users, no matter the Polarsys roadmap, and non-urgent needs will remain unfunded forever;
- A mandatory system is likely not to be approved.
Configuration Management is a transverse issue to Bug Fix and Feature Requests
Too many versions tends towards a custom development model and lowers economy of scale. In order to save money and allow affordable support, we need to tend to COTS.