PatchReversion

From Open64 Wiki

If a patch is committed which introduces a regression on any target which the Steering Group considers to be important and if:

  1. the problem is reported to the original poster; 
  2. 48 hours pass without the original poster or any other party
     indicating that a fix will be forthcoming in the very near future; 
  3. two people with write privileges to the affected area of the
     compiler determine that the best course of action is to revert the
     patch; then they may revert the patch;
  4. release manager will coordinate the investigation and hold the
     ultimate authority for patch reversion decision.

(The list of important targets will be revised at the beginning of each release cycle, if necessary, and is part of the release criteria.)

After the patch has been reverted, the poster may appeal the decision to the Steering Group. Note that no distinction is made between patches which are themselves buggy and patches that expose latent bugs elsewhere in the compiler.

Rationale

If an important platform is broken, then it will be difficult to prepare a release. If nobody volunteers to fix the problem, then we will have an unpleasant choice: delay the release, or release a compiler that we know to be worse than the previous release. Therefore, it is important that we be able to revert patches that cause problems. In addition, regressions on the mainline can impede the development of other improvements.

On the other hand, we want to encourage new development, and new development inevitably introduces new bugs. Therefore, it is important that decisions be made on a case-by-case basis, and that the proponent of a change has an opportunity to argue that the benefits of the change outweigh the costs. Therefore, the decision to revert requires two consenting parties, and such decisions may be appealed to the Steering Group. However, during the appeal, the mainline will remain working, to avoid impeding other development.