|Table of Contents|
Simply speaking, there are two broad categories of support provided for midPoint:
|Priority||Who can report||Usually used for||Typical reaction time|
(but no gurantees)
|Blocker||subscriber||Issues that block everything and everybody.|
Production environment is down.
Financial or reputation damage imminent.
Do not abuse this priority. Developers will drop everything and work on this issue. We will be very upset if this priority is abused.
Production environment is affected in a non-trivial way.
Risk of financial or reputation damage.
Quick (hours, days)
|Sometimes used by the development team to mark the most important features in a release. MidPoint won't be released unless all critical issues are addressed.|
May cause milestone delays. May cause release delays.
This priority is recommended for issues that affect production environment. Do not report issues with this priority that affect only testing or development environment, unless such issues are extremely serious. Use of this priority for deployment project is justified only if the issue blocks entire deployment team and the engineers are not able to proceed with any deployment tasks. Risk of project delays does not justify use of this priority. Deployment project should plan for sufficient reserves for issues discovered during the deployment.
Development or project is affected in a non-trivial way.
Risk of financial or reputation damage if the issue is not addressed eventually.
|Appropriate (weeks, months)|
Usually addressed within development milestone.
|Usually addressed within development milestone, but may be postponed to a final stabilization phase (after feature freeze) if needed. Major issues may block releases. But in rare cases even major issues can be postponed to the next release, but that needs to be negotiated with the subscriber.|
May cause release delays.
This is the highest priority to use for issues that affect testing and development environments, which is also the highest priority for deployment projects (given the exceptions mentioned above).
|Minor||subscriber, community||Minor nuisance.|
Makes life a bit harder, but not a big problem.
Negligible risk of financial or reputation damage.
|Eventual (months, years)|
Usually addressed within a release cycle. But no guarantees.
|Addressed during the final stabilization phase (after feature freeze). Development team will try to address as many minor issues as can fit into the development cycle. But it is almost certain that some of them will be left unsolved and moved out. Minor issue will never block a release.|
|Trivial||subscriber, community||Cosmetic issue.|
Not really important.
Just an idea.
No guarantees. No promises. No estimations.
|Can be freely moved in the plan. The most likely candidate to be moved when the time runs out.|
Development milestones were introduced in midPoint 4.0 release. Therefore please allow some time for the development process to adapt to this new regime. Therefore the times and procedures indicated above may slightly vary during the first few releases in the 4.x family. We kindly ask for patience and understanding. We are doing our best, but developers are people too.
MidPoint deployment projects have a lifecycle of their own. There is usually some exploration/preparation phase. Then there is development and testing. Then the project is deployed to production. Then further iterations follow. Characteristics of individual deployment phases considerably vary when it comes to impact and criticality of the issues. We have tuned our support model to provide the right balance for the needs of individual deployment phases. The guidelines are summarized in the following table:
|Phase||Maximum issue priority||Description|
This phase is usually not covered by any support or subscription. Therefore the maximum priority of an issue is minor, as that is the maximum priority of a community issue.
In case that this phase is indeed covered by support or subscription, then the same rules as for deployment/testing phase apply.
|Deployment and testing||Major|
Configuration is customized and tested, data migration is prepared and so on. But everything happens in the "lab" (development and/or testing environment). Production systems are not affected. MidPoint is not yet in the production, therefore the potential for any real harm is reduced. Therefore the maximum priority is reduced. This allows midPoint team to focus on more serious issues.
Please, be patient in this phase. Plan sufficient reserves in your project. Your issues may have lower priority now. But once you go to production you will surely appreciate that your issues will have a higher priority than the issues of new deployment projects.
MidPoint is running with real data. The deployment is supposed to be stable. MidPoint should not misbehave at this point. If midPoint happens to misbehave and there is a potential for harm, then such issue has to be fixed as soon as possible.
This also applies to security issues regardless of project phase.
|Follow-up iterations||Major||MidPoint deployment is in production - and the entry above applies to such production operation. However, there is often a new iteration started in parallel. Improved midPoint configuration is prepared in development environment, it is moved to testing after that, update of production environment is planned. Such follow-up iterations are handled in a same way as an original deployment project. While issues from the production environment can still be raised to the highest priorities, the issues that originate from development or testing environment have reduced priority.|
Those guidelines reflect our philosophy that prefers production deployments. While many products and programs are designed to support deployment projects where most of the money is generated, midPoint is quite different. We believe that the most important thing is to keep real (production) midPoint deployments running. The projects that are in the process of deploying midPoint can wait a bit. But production deployments that work with real data cannot wait. They need to have absolute priority.
This may seem harsh for deployment projects. But experienced deployment engineers and managers are already well-equipped for this. The project should proceed in smaller steps, testing the configuration is several iterations (prototyping), the project should have several alternative paths and the project plan should contain sufficient reserves for deployment issues. This is a best practice in the entire IT industry and IDM deployment projects are no exceptions here.
We would also like to emphasize the importance of deployment environments. MidPoint is especially designed for deployments that follow the "three environment model":
|Environment||Purpose||Maximux issue priotity|
Develop new configuration, configuration changes, prepare customizations, etc. MidPoint is connected to development instances of source/target systems. Some systems may be simulated.
Works with dummy data. Amount of data is usually reduced.
Test configurations after the development is done. Validate the system before deployment to production. MidPoint is connected to testing instances of source/target systems.
Works with simulated data, copy of real production data or anonymized production data. Same amount of data as in production environment.
MidPoint running with real source and target systems.
Works with real data.
Preparing and maintaining those three environments is strongly recommended for all deployment projects. Any significant change to the configuration should proceed from development environment to testing environment and only then it should be deployed to production.
There may be cases when those environments are not used and changes are done directly in production environment. Or cases, where development and testing environments are ineffective because the environment, configuration and data do not reflect the reality of production environment. We do not guarantee that our support services will be ideal fit for such environments. Both midPoint and our services were designed with proper engineering principles in mind and they were designed for deployments where such engineering principles are honored. In case that you are doing configuration changes directly in production environment, you should follow the priority limitations of development/testing environments. In such cases your first reaction to problems should be to roll back the configuration changes and revert to stable configuration. Which solves the problem. The sole fact that this problem was observed in production environment does not justify high priority of the issue.
Most issues cannot be properly addressed unless there is a good cooperation between issue reporter and developer. The developer often needs additional data for the issue. Our usual strategy for all issues is to follow test-driven bugfixing approach. Therefore we try to reproduce the issue in a controlled environment. Additional data are often needed to achieve that. We expect that it is a responsibility of the reporter to respond to requests for additional data. The usual communication is carried out by the means of comments in the issue tracking system.
We reserve the right to close the issue if the reporter does not respond to communication.
Those guidelines are designed to benefit the entire midPoint community. We do not look well at those that abuse those guidelines. MidPoint development and support team has finite resources. The abusers may get momentary advantage for themselves, but this approach distracts midPoint team from the tasks that are really important. Therefore we reserve to lower the priorities for reporters that repeatedly abuse those guidelines. This is the best approach for the entire midPoint community.