This page describes Apache CloudStack`s components retirement process.  We would love not to retire any component and integrate CloudStack with even more 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 or unused component is detected anyone can propose its retirement as long as the steps described here are followed;
  2. Create a discussion thread 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 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 Github Issue to disable the component/plugin is created. The Github Issue 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 date for the final removal should be defined and presented in this roadmap (six months after the finalisation of the voting thread);
  6. A patch (PR) to disable the code in the build must be created. This will require reviews and merge (our standard PR process is applied here);
  7. A Github Issue to execute the final removal of the code is created;
  8. When the final date comes by, a patch (PR) for the 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 these time lines, running emails threads, creating Github Issue 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 questions 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 always be removed.  Broken code should never be kept in our code base; it only slows down our development process and might serve as terrible example 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 the commit before the removal commit and then he/she can work 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. 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