|author||Russ Cox <email@example.com>||Thu Apr 25 23:21:12 2019 -0400|
|committer||Russ Cox <firstname.lastname@example.org>||Fri Apr 26 03:28:11 2019 +0000|
design/25530-sumdb: change /sumdb/supported to /sumdb/<sumdb-name>/supported Telling the proxy explicitly which checksum database we are asking about will make it possible, if there are ever multiple checksum databases, to access one database through one proxy and another through another proxy. As written before, that would be imposible. The old rationale for a single /sumdb/supported was to make it possible for corp proxies to say "I support all databases" and thereby intercept all possible database traffic. Those proxies can still do that by responding 200 to /sumdb/.*/supported. Change-Id: I8ce1a75d03e0d9dec8907fd3869cc8a83f82f831 Reviewed-on: https://go-review.googlesource.com/c/proposal/+/173946 Run-TryBot: Russ Cox <email@example.com> Reviewed-by: Russ Cox <firstname.lastname@example.org>
The Go project's development process is design-driven. Significant changes to the language, libraries, or tools must be first discussed, and sometimes formally documented, before they can be implemented.
This document describes the process for proposing, documenting, and implementing changes to the Go project.
The proposal process is the process for reviewing a proposal and reaching a decision about whether to accept or decline the proposal.
The proposal author creates a brief issue describing the proposal.
Note: There is no need for a design document at this point.
Note: A non-proposal issue can be turned into a proposal by simply adding the proposal label.
A discussion on the issue tracker aims to triage the proposal into one of three outcomes:
If the proposal is accepted or declined, the process is done. Otherwise the discussion is expected to identify concerns that should be addressed in a more detailed design.
The proposal author writes a design doc to work out details of the proposed design and address the concerns raised in the initial discussion.
Once comments and revisions on the design doc wind down, there is a final discussion on the issue, to reach one of two outcomes:
After the proposal is accepted or declined (whether after step 2 or step 4), implementation work proceeds in the same way as any other contribution.
The proposal process should be used for any notable change or addition to the language, libraries and tools. Since proposals begin (and will often end) with the filing of an issue, even small changes can go through the proposal process if appropriate. Deciding what is appropriate is matter of judgment we will refine through experience. If in doubt, file a proposal.
Programs written for Go version 1.x must continue to compile and work with future versions of Go 1. The Go 1 compatibility document describes the promise we have made to Go users for the future of Go 1.x. Any proposed change must not break this promise.
In 2018 we started a Go 2 process during which we may change the language, as described on the Go blog. Language changes should follow the proposal process described here. As explained in the blog entry, language change proposals should
(See the release notes for examples of recent language changes.)
As noted above, some (but not all) proposals need to be elaborated in a design document.
The design doc should be checked in to the proposal repository as
NNNN is the GitHub issue number and
shortname is a short name (a few dash-separated words at most). Clone this repository with
git clone https://go.googlesource.com/proposal and follow the usual Gerrit workflow for Go.
The design doc should follow the template.
The design doc should address any specific concerns raised during the initial discussion.
It is expected that the design doc may go through multiple checked-in revisions. New design doc authors may be paired with a design doc “shepherd” to help work on the doc.
For ease of review with Gerrit, design documents should be wrapped around the 80 column mark. Each sentence should start on a new line so that comments can be made accurately and the diff kept shorter.
fill.elfrom this directory will make
fill-paragraphformat text this way.
Comments on Gerrit CLs should be restricted to grammar, spelling, or procedural errors related to the preparation of the proposal itself. All other comments should be addressed to the related GitHub issue.
Experienced committers who are certain that a design doc will be required for a particular proposal can skip steps 1 and 2 and include the design doc with the initial issue.
In the worst case, skipping these steps only leads to an unnecessary design doc.
A group of Go team members holds “proposal review meetings” approximately weekly to review pending proposals.
The principal goal of the review meeting is to make sure that proposals are receiving attention from the right people, by cc'ing relevant developers, raising important questions, pinging lapsed discussions, and generally trying to guide discussion toward agreement about the outcome. The discussion itself is expected to happen on the issue tracker, so that anyone can take part.
The proposal review meetings also identify issues where consensus has been reached and the process can be advanced to the next step (by marking the proposal accepted or declined or by asking for a design doc).
The goal of the proposal process is to reach general consensus about the outcome in a timely manner.
If general consensus cannot be reached, the proposal review group decides the next step by reviewing and discussing the issue and reaching a consensus among themselves. If even consensus among the proposal review group cannot be reached (which would be exceedingly unusual), the arbiter (rsc@) reviews the discussion and decides the next step.
If you need help with this process, please contact the Go contributors by posting to the golang-dev mailing list. (Note that the list is moderated, and that first-time posters should expect a delay while their message is held for moderation.)
To learn about contributing to Go in general, see the contribution guidelines.