Child pages
  • Plugin/component retirement process
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

This page describes Apache CloudStack`s components retirement process.  We would love not to retire any component, and integrate 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 require pull requests (PRs) and a whole discussion, voting and other bureaucracy processes that is detailed as follows.

  1. When a broken and unused component is detected anyone can propose its retirement; as long as the steps described here are followed;
  2. Create a discussion thread report 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 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 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, a data 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 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 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.


Here goes some frequently asked question in respect to this issue:

  • Would not it be better to just disable and let the retired component there?
    No, it would not!
    Code that is not used should be removed.  Broken code should never be kept in our code base; it only slows down our development process and might serve as terrible examples for newcomers.
  • What if I someone in the future wants to get the retired component and put the energy and resources to make it alive again? Would not it be a good reason to keep the code?
    If someone desires to work on top of a retired plugin, anyone can do so by getting a commit before the removal commit and then working to resuscitate it. Therefore, there is no reason to keep the code. We use a versioning system; code removed/changed will always be in our history. That is why there is no need to keep things around if they are not used. Anyone using Git can easily recover a removed chunk of code.
  • Will you accept a resuscitated component?
    Yes, as long as it works, meets our quality standards, has user and maintainers.





  • No labels