Page History

This page describes Apache CloudStack`s components retirement process.  We would love not to retire any component , and integrate CloudStack with even more CloudStack with other software and systems. However, when some integration becomes broken and nobody else is using and willing to put the energy and resources required to properly maintain and develop it, then it is time to give some peace to the broken plugin. Retirement is a natural process; it is part of life! The retirement of an unused and broken component can free energy that can be directed to new and exciting features and integrations. The process occurs in two major steps, first disabling the build of the component, and later after a period of, at least, six (6) months, the retired component is removed.

The disabling and removal of the retired component

...

requires pull requests (PRs)

...

, discussion, voting and other bureaucracy processes that is detailed as follows.

1. When a broken and or unused component is detected anyone can propose its retirement ; as long as the steps described here are followed;
2. Create a discussion thread report reporting the situation and trying to discuss a way not to retire the component. If we find people willing to work on it, is great; otherwise, the retirement process continues;
3. After the discussion, a voting thread should be started to check if everybody in our community is on the same page; the voting windows window should be of 48 hours. If people are against, we keep discussing until we find a middle ground. Retirement is a very delicate process, so everybody should agree upon it;
4. If no objection arises or no one volunteers to maintain the code, a Jira ticket to disable the code component/plugin is created. The Jira ticket should describe the situation and link the discussion and voting threads;
5. An announce in our mailing lists of the road map of retirement , and a data date for the final removal should be defined and presented in this roadmap (six months after the finalization of the voting thread);
6. A patch (PR) to disable the code in the build will must be created. This will require reviews and merge (our standard PR process is applied here);
7. A Jira ticket to execute the final removal of the code is created;
8. When the final date comes by, a patch (PR) for the definite removal of the code is created. Again, this will require reviews and merge (our standard PR process is applied here). The contributor proposing the retirement should be in charge of managing this these time lines, running emails threads, creating Jira tickets and submitting PRs;
9. Congratulations!! You have removed an old and tired plugin; now, it (the retired plugin) can take the vacations it always dreamed of.

...