Skip to content

Make explicit that the CLC votes on implementation not design/Requires proposals for bug fixes. #352

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Make explicit that the CLC votes on implementation not design/Requires proposals for bug fixes. #352

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 10 additions & 1 deletion PROPOSALS.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -120,7 +120,7 @@ The following is a step by step guide for common proposals:
If your proposal is a "multi-phase proposal" with multiple implementation and deprecation steps, make sure to
precisely define when each step is supposed to take place.

### A note on stale proposals
### Stale proposals

The CLC can revoke its approval for a proposal if an **"activity"** has been overdue for over a year. The revocation request, which
explains what has changed with the passage of time to justify the review, can be initiated by the chair. If no CLC member vetos
Expand All @@ -131,6 +131,15 @@ the request, then it automatically passes.
- for a simple proposal: whether it has been merged
- for a multi-phase proposal: whether the next step has been carried out as planned

### `base` changes

Any GHC MR that changes a part of base under CLC purview requires a CLC proposal, pointing to the GHC MR, seeking approval from CLC of the changes to the base API.
This specifically includes:

* Bug-fixes that make a wrongly-implemented functions obey their specification.
Even if the change clearly fixes an outright bug.
* Performance improvements -- even if performance always improves.

## The "when"

If you've got a pet issue that's been sleeping in the depths of a mailing list
Expand Down
2 changes: 2 additions & 0 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -41,7 +41,9 @@ core-libraries-committee at haskell dot org
## `base` package

The primary responsibility of CLC is to manage API changes of `base` package. The ownership of `base` belongs to GHC developers, and they can maintain it freely without CLC involvement as long as changes are invisible to clients. Changes which affect performance or laziness and similar are deemed visible. Documentation changes normally fall under GHC developers purview, except significant ones (e. g., adding or changing type class laws).

Proposals to change the API of the `base` package are managed by the process, described in [`PROPOSALS.md`][proposals].
While design discussions and questions are welcome, the CLC will only vote on proposals that are accompanied by a concrete implementation (merge request)."

[proposals]: https://github.com/haskell/core-libraries-committee/blob/main/PROPOSALS.md

Expand Down