|author||Jaana Burcu Dogan <email@example.com>||Fri Jul 01 11:40:03 2016 -0700|
|committer||Jaana Burcu Dogan <firstname.lastname@example.org>||Sun Jul 10 01:19:26 2016 +0000|
design: tweak Clip interface to separate seeking Seeking within the audio source is not always a trivial problem, e.g. the cases where the underlying source is encoded with a VBR compression algorithm, optimistic seeking and slurping the entire data source may be required. Separation of the Seek method allows us to explain the requirements from the implementors more easily. Since different encoders will have different stragies to Seek, it is also easy to document the cost and the underlying algorithm to the users. Also, the seperation helps us document the requirements of implementing an efficient Clip.Frames. We are explecting decoders to have a cursor on the data source and move forward as new Frames calls arrive. We only expect them to modify the cursor if seeking is required. Without a separate Seek method, implementors need to check if the offset is matching with their current internal cursor and seek if it is not. Separation saves them figuring out the conditional case for a requirement of seeking. Change-Id: I0b15d56df9457a462953aaaf915445e268462f97 Reviewed-on: https://go-review.googlesource.com/24702 Reviewed-by: David Crawshaw <email@example.com>
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 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.
Go is a mature language and, as such, significant language changes are unlikely to be accepted. A “language change” in this context means a change to the Go language specification. (See the release notes for examples of recent language changes.)
Create an issue describing the proposal.
Like any GitHub issue, a Proposal issue is followed by an initial discussion about the suggestion. For Proposal issues:
It's always fine to label a suggestion issue with Proposal to opt in to this process.
It's always fine not to label a suggestion issue with Proposal. (If the suggestion needs a design doc or is declined but worth remembering, it is trivial to add the label later.)
If a Proposal issue leads to a design doc:
NNNNis the GitHub issue number and
shortnameis a short name (a few dash-separated words at most). Clone this repository with
git clone https://go.googlesource.com/proposaland follow the usual Gerrit workflow for Go.
Once comments and revisions on the design doc wind down, there is a final discussion about the proposal.
The author (and/or other contributors) do the work as described by the “Implementation” section of the proposal.
If you're already familiar with writing design docs for the Go project, the process has not changed much. The main thing that has changed is where the proposal is published.
In the situation where you'd write and circulate a design doc as a Google doc before, now you:
Worst case, by bypassing the initial discussion you've possibly written an unnecessary design doc. Not a big deal.
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.)
If you want to talk to someone off-list, contact Andrew Gerrand at firstname.lastname@example.org.
To learn about contributing to Go in general, see the contribution guidelines.