Pull Requests Submission Guide - facebook/jemalloc GitHub Wiki
Clear PRs make it easier for maintainers and contributors to quickly understand the purpose and impact of your changes. Use the following labels to improve clarity and consistency in your submissions.
PR Labels Overview
Each PR can be assigned one or more labels to indicate the type(s) of change included. Using appropriate labels helps reviewers understand your PR’s intent at a glance and enables faster review cycles. Labels are not exclusive—feel free to use all that apply!
| Label | Purpose |
|---|---|
| Bug Fix | Resolves a specific bug, error, or unintended behavior in the codebase. |
| Optimization | Improves the current implementation so that the same purpose can be served with lower CPU/memory overhead. |
| Enhancement/New Feature | Introduces a new feature guarded by compile-time or runtime options. |
| Cleanup | Improves code quality, readability, maintainability, or documentation. |
PR Description Templates
When submitting a PR, use the template that matches your PR’s primary label. Copy the template into your PR description and fill in the details.
Bug Fix PR
**Issue Reference**
Description or a link to the description of the bug.
**Root Cause**
Explain what caused the bug.
**Fix Details**
Describe the changes made to resolve the issue.
**Testing**
Describe how you tested the fix (e.g., new/updated tests, manual verification).
Optimization PR
**Background**
Explain the previous behavior or limitation.
**Optimization Details**
Describe the changes made and how they improve resource (CPU/memory) usage.
**Impact**
Summarize the expected impact (e.g., performance gains, reduced memory usage, and under what scenarios behavior is changed). Data in production or benchmark is required.
Enhancement (New Feature) PR
**Background**
Explain why the new feature or request is needed.
**Implementation details**
Explain the new compile-time or runtime options added. Introduce the expected behavior when the new options are on/off.
**Impact**
The CPU/memory changes with the new options on and off respectively. Data in production or benchmark is required.
Cleanup PR
**Motivation**
Explain why this cleanup was needed (e.g., code readability, maintainability, removing dead code).
**Changes**
Summarize the main changes (e.g., codes moved around and logics after refactoring).
**Testing**
Describe any testing done to ensure no functional changes were introduced.