mirror of
https://github.com/carbon-language/carbon-lang.git
synced 2026-09-24 20:00:12 +01:00
Chandler CarruthandRichard Smith
94d2c1c6d4
We've talked about adding the title to the filename several times over the years and it seems really valuable. This requires us to compute a "slug" for the title spelling that can be part of the filename. Beyond that, we crossed 7000 recently, and so it seems likely that we will need to add digits sooner rather than later here, so this goes ahead and moves us to 6 digits so we don't have to adjust again for a reasonable length of time. To implement this and ensure we can sustain it going forward this adds a tool to our pre-commit that validates (and corrects if needed) the filename. In order to update everything and keep links working, there are a _lot_ of changes, but the most interesting for direct review are in `proposals/scripts`. Assisted-by: Antigravity with Gemini --------- Co-authored-by: Richard Smith <richard@metafoo.co.uk>
125 lines
4.9 KiB
Markdown
125 lines
4.9 KiB
Markdown
# Getting commit access
|
|
|
|
<!--
|
|
Part of the Carbon Language project, under the Apache License v2.0 with LLVM
|
|
Exceptions. See /LICENSE for license information.
|
|
SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
|
-->
|
|
|
|
[Pull request](https://github.com/carbon-language/carbon-lang/pull/4246)
|
|
|
|
<!-- toc -->
|
|
|
|
## Table of contents
|
|
|
|
- [Abstract](#abstract)
|
|
- [Problem](#problem)
|
|
- [Background](#background)
|
|
- [Commit access](#commit-access)
|
|
- [Related policies](#related-policies)
|
|
- [Proposal](#proposal)
|
|
- [Rationale](#rationale)
|
|
- [Alternatives considered](#alternatives-considered)
|
|
- [Longer idle times](#longer-idle-times)
|
|
|
|
<!-- tocstop -->
|
|
|
|
## Abstract
|
|
|
|
Establish a process for getting commit access. We will:
|
|
|
|
- Grant access based on a developer's commit history.
|
|
- Someone with commit access should nominate, and a contributor may ask.
|
|
- A lead will approve nominations. Only one lead is needed.
|
|
- Remove commit access once someone is idle for 6 months.
|
|
- "Idle" means no significant project activity on any of GitHub, Discord,
|
|
or in meetings.
|
|
- Access removed due to being idle will be restored on request.
|
|
|
|
## Problem
|
|
|
|
Right now, we have an undocumented process for getting commit access, and no
|
|
real agreement for when to remove it. Commit access is important, so rather than
|
|
just making a documentation edit, I'm submitting this as a proposal.
|
|
|
|
## Background
|
|
|
|
### Commit access
|
|
|
|
When we say "commit access", what we mean is the ability to push commits to the
|
|
main `carbon-lang` repository, regardless of branch. Some details about the
|
|
implications:
|
|
|
|
- Review and approvals would remain required for pushes to `trunk`.
|
|
- This does grant access to push to other branches, although we will
|
|
continue to encourage fork-based workflows.
|
|
- Pushing PRs becomes easier with commit access.
|
|
- Action workflows will automatically execute, instead of requiring a
|
|
per-commit approval by someone with commit access.
|
|
- Modifying PRs after review approval is possible.
|
|
- This is both good (for small updates such as fixing typos and
|
|
resolving conflicts) and bad (particularly for code security).
|
|
- Communication delays can make it hard for an author to resolve conflicts
|
|
and reviewer to approve and merge before more conflicts are introduced.
|
|
- A possible solution to the conflict problem is to have the reviewer
|
|
merge PRs more frequently, and regardless of any decision here, we
|
|
may eventually need to adopt that approach.
|
|
- Commit access functionally means the ability to approve and merge PRs from
|
|
others.
|
|
- As alternatives, we could use either a separate GitHub team for
|
|
approvals or
|
|
[CODEOWNERS](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners).
|
|
We have avoided these so far because we're small, having backup
|
|
approvers can be helpful, and mistakes are easy to undo.
|
|
- This does not include the ability to push to other repositories. While there
|
|
are a few in the `carbon-language` organization, only the `carbon-lang`
|
|
repository is actively used.
|
|
- People with commit access in effect have access to secrets, can make
|
|
releases, and so on.
|
|
|
|
### Related policies
|
|
|
|
This proposal does not supersede other project policies, in particular:
|
|
|
|
- [CLA](/CONTRIBUTING.md#contributor-license-agreements-clas)
|
|
- [Code of Conduct](/CODE_OF_CONDUCT.md)
|
|
- [Review process](/docs/project/code_review.md)
|
|
|
|
## Proposal
|
|
|
|
The key things I think should be covered in this proposal are:
|
|
|
|
- Whether we want to require a lead to approve commit access additions.
|
|
- We're choosing to do a 6 month inactive period for removal.
|
|
|
|
Things I think we should be okay iterating on without going through evolution
|
|
include:
|
|
|
|
- Exactly how we define non-idle activity beyond merging and approving PRs,
|
|
both of which mechanically require this access.
|
|
- The detailed process for additions, including nominating.
|
|
- We want a good starting point, but it may not be worth sending all
|
|
changes through the proposal process.
|
|
- The detailed process for removals, such as whether leads are approving
|
|
removals.
|
|
- This is something it's been suggested to fully automate, preventing
|
|
review of removals.
|
|
|
|
See the new [Commit access](/docs/project/commit_access.md) document for
|
|
details.
|
|
|
|
## Rationale
|
|
|
|
- [Community and culture](/docs/project/goals.md#community-and-culture)
|
|
- Establishing the processes around commit access, and making sure they're
|
|
reasonable, is important to maintaining the community.
|
|
|
|
## Alternatives considered
|
|
|
|
### Longer idle times
|
|
|
|
We discussed using a longer idle time, like 1, 2, or 3 years. We're leaning
|
|
towards the shorter 6 month period because of concerns about forgotten access
|
|
causing issues. We're hoping 6 months is a minimum of inconvenience, and want it
|
|
to be easy to get access back on request.
|