| MEP | 1 |
| Author | Jan Decaluwe, Günter Dannoritzer |
| Status | Active |
| Created | 18-May-2011 |
What is a MEP?
MEP stands for MyHDL Enhancement Proposal. A MEP is a design document providing information to the MyHDL community, or describing a new feature for MyHDL. The MEP should provide a concise technical specification of the feature and a rationale for the feature.
The MEP concept is heavily inspired by the PEP, the Python Enhancement Proposal. In the Python world, the PEP works very well, and a MEP is basically a simplified version for our purposes.
We intend MEPs to be the primary mechanisms for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into MyHDL. The MEP author is responsible for building consensus within the community and documenting dissenting opinions.
MEP development
MEPs are maintained on the MyHDL development website, which is developed in the MyHDL development website repository. This is a public repository that documents the history of a MEP.
The main responsibility of a MEP lies with its author. Before starting a new MEP, its idea should be discussed on the MyHDL mailing list.
Policy
In the development phase, the MEP is assigned the Draft status. When fully developed and provided with a functional implementation, the MEP can get the status Final, documenting that the content of the MEP is ready to be implemented into MyHDL.
A MEP can also become Rejected if it turned out to be not a good idea.
The right to change the status of a MEP from Draft belongs exclusively to Jan Decaluwe.
Once the MEP has the status Final and it is implemented in the source code, the MyHDL version will be added to the MEP document. From this time on, the text of the document will be frozen. A Final MEP should not be changed, except for spelling mistakes or language corrections from a neutral proofreader. It is intended to document the MyHDL development history for experts.
In case the functionality described in a MEP needs to be altered or extended, a new MEP shall be created, describing the new desired implementation. The new MEP will live through the same steps as the MEP process describes. The new MEP should cross reference the MEP its implementation is based on.
In case the new MEP will replace an implementation of an existing MEP, the old MEP will get the status Replaced as soon as the new MEP achieves the status Final. Both MEPs should cross reference each other.
Informational MEPs may also get the status Active if they are not meant to be completed. This MEP is an example.