Jump to: navigation, search

Difference between revisions of "Polarsys/UseCases"

(Bug fix)
Line 1: Line 1:
=Support without software change=
+
=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>
  
=Bug fix=
+
A solution could be the following:
How to ensure that a bug can be fixed.<br>
+
* Users that want professional support subscribe to a professional services offer provided by a Branded Polarsys Provider, which could include:
Support subscription for the tools they use? => ensure quick fix
+
** 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.
  
# Users that want professional support subscribe to a professional services offer provided by a Branded Polarsys Provider.
+
Open questions:
# Branded Polarsys Providers must offer added value in addition to raw Polarsys added Value. This added value could be providing validated binaries that are not provided.
+
# Support Contracts are accessible only to Polarsys members ?
 
+
# who controls the Polarsys VLTS branch ?
Support contracts should include best practices:
+
# What if there is no Branded provider in a given area ?
* All patches should be given back to the Polarsys LTS branch
+
* Or there should be a good technical or confidentiality reason explained.
+
Support Contracts are accessible only to Polarsys members.
+
  
 
=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=
Two many versions tends towards a custom development model and lowers economy
+
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 11: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:

  1. Support Contracts are accessible only to Polarsys members ?
  2. who controls the Polarsys VLTS branch ?
  3. 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.