Skip to content

Commit

Permalink
deploy: 8c11565
Browse files Browse the repository at this point in the history
  • Loading branch information
zhangyangyu committed Apr 13, 2024
1 parent 1cfb662 commit e9e2779
Show file tree
Hide file tree
Showing 44 changed files with 643 additions and 641 deletions.
18 changes: 9 additions & 9 deletions contribute-to-tidb/code-style-and-quality-guide.html
Original file line number Diff line number Diff line change
Expand Up @@ -185,25 +185,25 @@ <h2 id="the-newtype-pattern-improves-code-quality"><a class="header" href="#the-
<pre><code class="language-go">package main

import (
&quot;fmt&quot;
&quot;strings&quot;
"fmt"
"strings"
)

type Email string

func newEmail(email string) (Email, error) {
if !strings.Contains(email, &quot;@&quot;) {
return Email(&quot;&quot;), fmt.Errorf(&quot;Expected @ in the email&quot;)
if !strings.Contains(email, "@") {
return Email(""), fmt.Errorf("Expected @ in the email")
}
return Email(email), nil
}

func (email Email) Domain() string {
return strings.Split(string(email), &quot;@&quot;)[1]
return strings.Split(string(email), "@")[1]
}

func main() {
ping, err := newEmail(&quot;[email protected]&quot;)
ping, err := newEmail("[email protected]")
if err != nil { panic(err) }
fmt.Println(ping.Domain())
}
Expand All @@ -226,7 +226,7 @@ <h2 id="when-to-use-value-or-pointer-receiver"><a class="header" href="#when-to-
<li>What is the GC behavior of the rest of the program? GC pressure may favor value receivers.</li>
</ul>
<h2 id="parallel-for-loop"><a class="header" href="#parallel-for-loop">Parallel For-Loop</a></h2>
<p>There are two types of for loop on range: &quot;with index&quot; and &quot;without index&quot;. Let's see an example for range with index.</p>
<p>There are two types of for loop on range: "with index" and "without index". Let's see an example for range with index.</p>
<pre><code class="language-go">func TestRangeWithIndex(t *testing.T) {
rows := []struct{ index int }{{index: 0}, {index: 1}, {index: 2}}
for _, row := range rows {
Expand All @@ -248,7 +248,7 @@ <h2 id="parallel-for-loop"><a class="header" href="#parallel-for-loop">Parallel
<h3 id="the-same-instance-of-the-variable"><a class="header" href="#the-same-instance-of-the-variable">The same instance of the variable</a></h3>
<p>Since the the loop iterator variable is the same instance of the variable, it may result in tricky error with parallel for-loop.</p>
<pre><code class="language-go">done := make(chan bool)
values := []string{&quot;a&quot;, &quot;b&quot;, &quot;c&quot;}
values := []string{"a", "b", "c"}
for _, v := range values {
go func() {
fmt.Println(v)
Expand All @@ -259,7 +259,7 @@ <h3 id="the-same-instance-of-the-variable"><a class="header" href="#the-same-ins
&lt;-done
}
</code></pre>
<p>You might expect to see <code>a</code>, <code>b</code>, <code>c</code> as the output, but you'll probably see instead is <code>c</code>, <code>c</code>, <code>c</code>. </p>
<p>You might expect to see <code>a</code>, <code>b</code>, <code>c</code> as the output, but you'll probably see instead is <code>c</code>, <code>c</code>, <code>c</code>.</p>
<p>This is because each iteration of the loop uses the same instance of the variable <code>v</code>, so each closure shares that single variable.</p>
<p>This is the same reason which result wrong test when use <code>t.Parallel()</code> with range, which is covered in <a href="../get-started/write-and-run-unit-tests.html#parallel">Parallel section of Write and run unit tests</a></p>
<h3 id="a-clone-of-iteration-target-value"><a class="header" href="#a-clone-of-iteration-target-value">A clone of iteration target value</a></h3>
Expand Down
2 changes: 1 addition & 1 deletion contribute-to-tidb/committer-guide.html
Original file line number Diff line number Diff line change
Expand Up @@ -205,7 +205,7 @@ <h2 id="shepherd-a-pull-request"><a class="header" href="#shepherd-a-pull-reques
</ul>
<h2 id="time-management"><a class="header" href="#time-management">Time Management</a></h2>
<p>There are many things that a committer can do, such as moderating discussions, pull request reviews and code contributions.</p>
<p>Working on an open source project can be rewarding, but also be a bit overwhelming sometimes. A little bit of time management might be helpful to alleviate the problem. For example, some committers have a &quot;community day&quot; in a week when they actively manage outstanding PRs, but watch the community less frequently in the rest of the time.</p>
<p>Working on an open source project can be rewarding, but also be a bit overwhelming sometimes. A little bit of time management might be helpful to alleviate the problem. For example, some committers have a "community day" in a week when they actively manage outstanding PRs, but watch the community less frequently in the rest of the time.</p>
<p>Remember that your merit will never go away, so please take your time and pace when contributing to the project:)</p>

</main>
Expand Down
4 changes: 2 additions & 2 deletions contribute-to-tidb/contribute-code.html
Original file line number Diff line number Diff line change
Expand Up @@ -180,7 +180,7 @@ <h1 id="contribute-code"><a class="header" href="#contribute-code">Contribute Co
<p>TiDB is maintained, improved, and extended by code contributions. We welcome code contributions to TiDB. TiDB uses a workflow based on <a href="https://docs.github.com/en/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests">pull requests</a>.</p>
<h2 id="before-contributing"><a class="header" href="#before-contributing">Before contributing</a></h2>
<p>Contributing to TiDB does <em>not</em> start with opening a pull request. We expect contributors to reach out to us first to discuss the overall approach together. Without consensus with the TiDB committers, contributions might require substantial rework or will not be reviewed. So please <a href="report-an-issue.html">create a GitHub issue</a>, discuss under an existing issue, or create a topic on the <a href="https://internals.tidb.io">internal.tidb.io</a> and reach consensus.</p>
<p>For newcomers, you can check the <a href="https://github.com/pingcap/tidb/contribute">starter issues</a>, which are annotated with a &quot;good first issue&quot; label. These are issues suitable for new contributors to work with and won't take long to fix. But because the label is typically added at triage time it can turn out to be inaccurate, so do feel free to leave a comment if you think the classification no longer applies.</p>
<p>For newcomers, you can check the <a href="https://github.com/pingcap/tidb/contribute">starter issues</a>, which are annotated with a "good first issue" label. These are issues suitable for new contributors to work with and won't take long to fix. But because the label is typically added at triage time it can turn out to be inaccurate, so do feel free to leave a comment if you think the classification no longer applies.</p>
<p>To get your change merged you need to sign the <a href="https://cla-assistant.io/pingcap/tidb">CLA</a> to grant PingCAP ownership of your code.</p>
<h2 id="contributing-process"><a class="header" href="#contributing-process">Contributing process</a></h2>
<p>After a consensus is reached in issues, it's time to start the code contributing process:</p>
Expand Down Expand Up @@ -215,7 +215,7 @@ <h2 id="making-good-pull-requests"><a class="header" href="#making-good-pull-req
<li>Does the contribution alter the behavior of features or components in a way that it may break previous users' programs and setups? If yes, there needs to be a discussion and agreement that this change is desirable.</li>
<li>Does the contribution conceptually fit well into TiDB? Is it too much of a special case such that it makes things more complicated for the common case, or bloats the abstractions/APIs?</li>
<li>Does the contribution make a big impact on TiDB's build time?</li>
<li>Does your contribution affect any documentation? If yes, you should add/change proper documentation. </li>
<li>Does your contribution affect any documentation? If yes, you should add/change proper documentation.</li>
<li>If there are any new dependencies, are they under active maintenances? What are their licenses?</li>
</ul>
<h2 id="making-good-commits"><a class="header" href="#making-good-commits">Making good commits</a></h2>
Expand Down
4 changes: 2 additions & 2 deletions contribute-to-tidb/make-a-proposal.html
Original file line number Diff line number Diff line change
Expand Up @@ -180,7 +180,7 @@ <h1 id="make-a-proposal"><a class="header" href="#make-a-proposal">Make a Propos
<p>This page defines the best practices procedure for making a proposal in TiDB projects. This text is based on the content of <a href="https://github.com/pingcap/tidb/blob/7f4f5c02364b6578da561ec14f409a39ddf954a5/docs/design/README.md">TiDB Design Document</a>.</p>
<h2 id="motivation"><a class="header" href="#motivation">Motivation</a></h2>
<p>Many changes, including bug fixes and documentation improvements can be implemented and reviewed via the normal GitHub pull request workflow.</p>
<p>Some changes though are &quot;substantial&quot;, and we ask that these be put through a bit of a design process and produce a consensus among the TiDB community.</p>
<p>Some changes though are "substantial", and we ask that these be put through a bit of a design process and produce a consensus among the TiDB community.</p>
<p>The process described in this page is intended to provide a consistent and controlled path for new features to enter the TiDB projects, so that all stakeholders can be confident about the direction the projects is evolving in.</p>
<h2 id="who-should-initiate-the-design-document"><a class="header" href="#who-should-initiate-the-design-document">Who should initiate the design document?</a></h2>
<p>Everyone is encouraged to initiate a design document, but before doing it, please make sure you have an intention of getting the work done to implement it.</p>
Expand All @@ -200,7 +200,7 @@ <h2 id="what-is-the-process"><a class="header" href="#what-is-the-process">What
<li>Start the implementation.</li>
</ol>
<p>Please refer to the tracking issue from subtasks to track the progress.</p>
<p>An example that almost fits into this model is the proposal &quot;Support global index for partition table&quot;, without following the latest template.</p>
<p>An example that almost fits into this model is the proposal "Support global index for partition table", without following the latest template.</p>
<ul>
<li><a href="https://github.com/pingcap/tidb/issues/18032">tracking issue</a></li>
<li><a href="https://github.com/pingcap/tidb/pull/18982">pull request of design document</a></li>
Expand Down
4 changes: 2 additions & 2 deletions contribute-to-tidb/release-notes-style-guide.html
Original file line number Diff line number Diff line change
Expand Up @@ -214,7 +214,7 @@ <h2 id="compatibility-change"><a class="header" href="#compatibility-change">Com
</tbody></table>
</div>
<h2 id="bug-fix"><a class="header" href="#bug-fix">Bug fix</a></h2>
<p>A bug fix note means that your PR fixes an existing bug or issue. This type of notes start with &quot;Fix&quot; followed by &quot;the issue/bug&quot;.</p>
<p>A bug fix note means that your PR fixes an existing bug or issue. This type of notes start with "Fix" followed by "the issue/bug".</p>
<p>Write your note clearly and adequately so that your target readers can get the main point of your bug fix. The bug or issue must be directly perceivable to the users, and you can refer to the associated GitHub issues.</p>
<p>In addition, it is recommended to highlight the bug trigger condition or the workaround if there is any.</p>
<p><strong>Examples:</strong></p>
Expand All @@ -227,7 +227,7 @@ <h2 id="bug-fix"><a class="header" href="#bug-fix">Bug fix</a></h2>
</div>
<h2 id="improvement"><a class="header" href="#improvement">Improvement</a></h2>
<p>An improvement note means that your PR improves stability or performance of the product, or enhances an existing feature. In addition to describing what your PR has changed, you should also mention how users can benefit from it.</p>
<p>This type of release note consists of two parts: what you have changed + the benefit of your change. This type of release notes often starts with &quot;support&quot;, &quot;increase&quot;, &quot;improve&quot;, &quot;optimize&quot;, etc.</p>
<p>This type of release note consists of two parts: what you have changed + the benefit of your change. This type of release notes often starts with "support", "increase", "improve", "optimize", etc.</p>
<p><strong>Examples:</strong></p>
<div class="table-wrapper"><table><thead><tr><th><strong>Not recommended</strong></th><th><strong>Clear in type</strong></th><th><strong>Adequate and clear in meaning</strong></th><th><strong>User perspective</strong></th><th>Recommended</th></tr></thead><tbody>
<tr><td>Not use the stale read request's <code>start_ts</code> to update <code>max_ts</code> to avoid commit request keep retrying</td><td></td><td></td><td></td><td>Improve commit performance in some edge cases</td></tr>
Expand Down
4 changes: 2 additions & 2 deletions contribute-to-tidb/report-an-issue.html
Original file line number Diff line number Diff line change
Expand Up @@ -188,8 +188,8 @@ <h2 id="filing-an-issue"><a class="header" href="#filing-an-issue">Filing an iss
<li>What did you see instead?</li>
<li>What is your TiDB version?</li>
</ul>
<p>Answering these questions give the details about your problem so other contributors or TiDB users could pick up your issue more easily. </p>
<p>As previous section shows, duplicated issues should be reduced. To help others who encountered the problem find your issue, except for problem details answered in the issue template, a descriptive title which contains information that might be unique to it also helps. This can be the components your issue belongs to or database features used in your issue, the conditions that trigger the bug, or part of the error message if there is any. </p>
<p>Answering these questions give the details about your problem so other contributors or TiDB users could pick up your issue more easily.</p>
<p>As previous section shows, duplicated issues should be reduced. To help others who encountered the problem find your issue, except for problem details answered in the issue template, a descriptive title which contains information that might be unique to it also helps. This can be the components your issue belongs to or database features used in your issue, the conditions that trigger the bug, or part of the error message if there is any.</p>
<h2 id="making-good-issues"><a class="header" href="#making-good-issues">Making good issues</a></h2>
<p>Except for a good title and detailed issue message, you can also add suitable labels to your issue via <a href="https://prow.tidb.io/command-help?repo=pingcap%2Ftidb#type">/label</a>, especially which component the issue belongs to and which versions the issue affects. Many committers and contributors only focus on certain subsystems of TiDB. Setting the appropriate component is important for getting their attention. Some issues might affect multiple releases. You can query <a href="issue-triage.html">Issue Triage chapter</a> for more information about what need to do with such issues.</p>
<p>If you are able to, you should take more considerations on your issue:</p>
Expand Down
4 changes: 2 additions & 2 deletions contribute-to-tidb/review-a-pr.html
Original file line number Diff line number Diff line change
Expand Up @@ -189,7 +189,7 @@ <h2 id="principles-of-the-code-review"><a class="header" href="#principles-of-th
<li>Suppose that a pull request contains special optimization that can improve the overall performance by 30%. However, the pull request introduces a totally different code path, and every subsequent feature must consider it.</li>
<li>Suppose that a pull request is to fix a critical bug, but the change in the pull request is risky to introduce other bugs.</li>
</ul>
<p>If a pull request under your review is in these tricky situations, what is the right choice, accepting the pull request or rejecting it? The answer is always &quot;it depends.&quot; Software design is more like a kind of art than technology. It is about aesthetics and your taste of the code. There are always trade-offs, and often there's no perfect solution.</p>
<p>If a pull request under your review is in these tricky situations, what is the right choice, accepting the pull request or rejecting it? The answer is always "it depends." Software design is more like a kind of art than technology. It is about aesthetics and your taste of the code. There are always trade-offs, and often there's no perfect solution.</p>
<h2 id="triaging-pull-requests"><a class="header" href="#triaging-pull-requests">Triaging pull requests</a></h2>
<p>Some pull request authors may not be familiar with TiDB, TiDB development workflow or TiDB community. They don't know what labels should be added to the pull requests and which experts could be asked for review. If you are able to, it would be great for you to triage the pull requests, adding suitable labels to the pull requests, asking corresponding experts to review the pull requests. These actions could help more contributors notice the pull requests and make quick responses.</p>
<h2 id="checking-pull-requests"><a class="header" href="#checking-pull-requests">Checking pull requests</a></h2>
Expand All @@ -208,7 +208,7 @@ <h2 id="writing-code-review-comments"><a class="header" href="#writing-code-revi
<li><strong>Be respectful to pull request authors and other reviewers</strong>. Code review is a part of your community activities. You should follow the community requirements.</li>
<li><strong>Asking questions instead of making statements</strong>. The wording of the review comments is very important. To provide review comments that are constructive rather than critical, you can try asking questions rather than making statements.</li>
<li><strong>Offer sincere praise</strong>. Good reviewers focus not only on what is wrong with the code but also on good practices in the code. As a reviewer, you are recommended to offer your encouragement and appreciation to the authors for their good practices in the code. In terms of mentoring, telling the authors what they did is right is even more valuable than telling them what they did is wrong.</li>
<li><strong>Provide additional details and context of your review process</strong>. Instead of simply &quot;approving&quot; the pull request. If you test the pull request, report the result and your test environment details. If you request changes, try to suggest how.</li>
<li><strong>Provide additional details and context of your review process</strong>. Instead of simply "approving" the pull request. If you test the pull request, report the result and your test environment details. If you request changes, try to suggest how.</li>
</ul>
<h2 id="accepting-pull-requests"><a class="header" href="#accepting-pull-requests">Accepting pull requests</a></h2>
<p>Once you think the pull request is ready, you can <a href="https://docs.github.com/en/github/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/approving-a-pull-request-with-required-reviews">approve</a> it, commenting with <code>/lgtm</code> is also valid.</p>
Expand Down
Loading

0 comments on commit e9e2779

Please sign in to comment.