This is an automated email from the ASF dual-hosted git repository.
git-site-role pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/drill-site.git
The following commit(s) were added to refs/heads/asf-site by this push:
new b2e5647 Automatic Site Publish by Buildbot
b2e5647 is described below
commit b2e56477b832f96c3385d13e735ce197301c6d8c
Author: buildbot <[email protected]>
AuthorDate: Mon Jan 3 11:43:37 2022 +0000
Automatic Site Publish by Buildbot
---
output/blog/index.html | 2 +-
.../docs/apache-drill-contribution-guidelines/index.html | 16 ++++++++--------
output/feed.xml | 4 ++--
output/zh/blog/index.html | 2 +-
.../docs/apache-drill-contribution-guidelines/index.html | 16 ++++++++--------
output/zh/feed.xml | 4 ++--
6 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/output/blog/index.html b/output/blog/index.html
index 6dbfb2e..bf1b6c1 100644
--- a/output/blog/index.html
+++ b/output/blog/index.html
@@ -340,7 +340,7 @@ by Tomer Shiran</span>
by Anil Kumar Batchu, Kamesh Bhallamudi</span>
<br/>The MongoDB storage plugin for Drill enables analytical queries on
MongoDB databases. Drill's schema-free JSON data model is a natural fit for
MongoDB's data model.</p>
-<p class="info">Want to contribute a blog post? Check out the source for some
of the <a
href="https://github.com/apache/drill/tree/gh-pages/blog/_posts";>existing
posts</a> to see how it's done. When you're ready, email your Markdown file to
<a href="mailto:[email protected]";>[email protected]</a>.</p>
+<p class="info">Want to contribute a blog post? Check out the source for some
of the <a
href="https://github.com/apache/drill-site/tree/master/blog/_posts";>existing
posts</a> to see how it's done. When you're ready, email your Markdown file to
<a href="mailto:[email protected]";>[email protected]</a>.</p>
<h1>Third-Party Articles</h1>
<!-- previously: site.posts -->
<p><a class="post-link"
href="https://www.mapr.com/blog/how-turn-raw-data-yelp-insights-minutes-apache-drill";>How
to Turn Raw Data from Yelp into Insights in Minutes with Apache Drill</a> (Nov
13, 2014)<br/></p>
diff --git a/output/docs/apache-drill-contribution-guidelines/index.html
b/output/docs/apache-drill-contribution-guidelines/index.html
index ae9ec5a..7f34364 100644
--- a/output/docs/apache-drill-contribution-guidelines/index.html
+++ b/output/docs/apache-drill-contribution-guidelines/index.html
@@ -1526,7 +1526,7 @@ following settings into your browser:</p>
<ol>
<li>The contributor writes the code that addresses a specific JIRA report as
a contribution to the Apache Drill project.</li>
- <li>The contributor organizes (squashes) their code into commits that
segregate out refactoring/reorg, as necessary, to enable efficient review. The
following list identifies how to combine code into commits:<br />
+ <li>The contributor organizes (squashes) their code into commits that
segregate out refactoring/reorg, as necessary, to enable efficient review. The
following list identifies how to combine code into commits:
* Combine WIP and other small commits together.
* Address multiple JIRAs, for smaller bug fixes or enhancements, with a
single commit.
* Use separate commits to allow efficient review, separating out
formatting changes or simple refactoring from core changes or additions.
@@ -1546,7 +1546,7 @@ following settings into your browser:</p>
<li>The contributor asks a committer who has experience with the affected
component for review.
This information can be found in the <a
href="https://issues.apache.org/jira/browse/DRILL/?selectedTab=com.atlassian.jira.jira-projects-plugin:components-panel";>component
owners</a> section of JIRA, or by running <code class="language-plaintext
highlighter-rouge">git blame</code> on the primary files changed in the pull
request. For pull requests that affect multiple areas, send a message to the
dev list to find a reviewer.</li>
<li>The contributor sets the Reviewer field to the assigned reviewer and
marks the status as REVIEWABLE.</li>
- <li>The reviewer reviews the pull request in GitHub and adds comments or a
+1 to the general discussion if the pull request is ready to commit.<br />
+ <li>The reviewer reviews the pull request in GitHub and adds comments or a
+1 to the general discussion if the pull request is ready to commit.
* If there are issues to address, the reviewer changes the JIRA status to
“In Progress.”
* If the reviewer gives a +1, the reviewer adds a “ready-to-commit” label
to the Labels field in the Jira. The contributor should continue to step 9 in
this process.</li>
<li>The contributor addresses review comments. This can be done with new
commits on the branch or with work made on the branch locally, squashed into
the commit(s) posted in the original pull request and force pushed to the
branch the pull request is based on.</li>
@@ -1556,8 +1556,8 @@ This information can be found in the <a
href="https://issues.apache.org/jira/bro
* If the master branch has moved forward since the review, rebase the
branch from the pull request on the latest master and re-run tests.
* If all tests pass, the committer amends the last commit message in the
series to include “this closes #1234”, where 1234 is the pull request number,
not the JIRA number. This can be done with interactive rebase. When on the
branch issue:</p>
- <div class="language-plaintext highlighter-rouge"><div
class="highlight"><pre class="highlight"><code> git rebase -i HEAD^
-* Change where it says “pick” on the line with the last commit, replacing it
with “r” or “reword”. It replays the commit giving you the opportunity the
change the commit message.
+ <div class="language-plaintext highlighter-rouge"><div
class="highlight"><pre class="highlight"><code> git rebase -i HEAD^
+* Change where it says “pick” on the line with the last commit, replacing it
with “r” or “reword”. It replays the commit giving you the opportunity the
change the commit message.
* The committer pushes the commit(s) to the Apache repo (the GitHub repo is
just a read-only mirror).
* The committer resolves the JIRA with a message like `"Fixed in <Git
commit SHA>"`.
</code></pre></div> </div>
@@ -1579,7 +1579,7 @@ This information can be found in the <a
href="https://issues.apache.org/jira/bro
<p>After getting the source code, building and running a few simple queries,
one
of the simplest places to start is to implement a DrillFunc. DrillFuncs are
the way that Drill expresses all scalar functions (UDF or system).</p>
-<p>First you can put together a JIRA for one of the DrillFuncs that we don’t
yet have, but should (referencing the capabilities of something like
Postgres<br />
+<p>First you can put together a JIRA for one of the DrillFuncs that we don’t
yet have, but should (referencing the capabilities of something like Postgres
or SQL Server). Then try to implement one.</p>
<p>See this example DrillFunc:</p>
@@ -1613,12 +1613,12 @@ this history of the discussion.</p>
<li>HOWTOs for using Drill with other popular software.</li>
</ol>
-<p>Documentation committed into the <code class="language-plaintext
highlighter-rouge">gh-pages</code> branch does not have any effect on the Drill
code base and so does not require a JIRA ticket or a corresponding PR from a
repo fork. It does still require a Drill committer to check it and push it
into the Drill code repo. This means</p>
+<p>Documentation committed to the apache/drill-site repository doesn’t have
any effect on the Drill code base and so does not require a JIRA ticket. It
does still require a Drill committer to check it and push it into the Drill
code repo. This means</p>
<ol>
- <li>Drill committers can add documentation with little bureaocratic
overhead.</li>
+ <li>Drill committers can add documentation with little bureaucratic
overhead.</li>
<li>Anyone can send documentation to a Drill committer (find us on Slack or
the mailing lists) as
-markdown or plain text and the committer can incorporate it with little
bureaocratic overhead.</li>
+markdown or plain text and the committer can incorporate it with little
bureaucratic overhead.</li>
</ol>
<h3 id="see-also">See Also</h3>
diff --git a/output/feed.xml b/output/feed.xml
index e67eb4d..251d661 100644
--- a/output/feed.xml
+++ b/output/feed.xml
@@ -6,8 +6,8 @@
</description>
<link>/</link>
<atom:link href="/feed.xml" rel="self" type="application/rss+xml"/>
- <pubDate>Mon, 03 Jan 2022 08:50:01 +0000</pubDate>
- <lastBuildDate>Mon, 03 Jan 2022 08:50:01 +0000</lastBuildDate>
+ <pubDate>Mon, 03 Jan 2022 11:41:13 +0000</pubDate>
+ <lastBuildDate>Mon, 03 Jan 2022 11:41:13 +0000</lastBuildDate>
<generator>Jekyll v3.9.1</generator>
<item>
diff --git a/output/zh/blog/index.html b/output/zh/blog/index.html
index 2185e0c..1284285 100644
--- a/output/zh/blog/index.html
+++ b/output/zh/blog/index.html
@@ -340,7 +340,7 @@ by Tomer Shiran</span>
by Anil Kumar Batchu, Kamesh Bhallamudi</span>
<br/>The MongoDB storage plugin for Drill enables analytical queries on
MongoDB databases. Drill's schema-free JSON data model is a natural fit for
MongoDB's data model.</p>
-<p class="info">Want to contribute a blog post? Check out the source for some
of the <a
href="https://github.com/apache/drill/tree/gh-pages/blog/_posts";>existing
posts</a> to see how it's done. When you're ready, email your Markdown file to
<a href="mailto:[email protected]";>[email protected]</a>.</p>
+<p class="info">Want to contribute a blog post? Check out the source for some
of the <a
href="https://github.com/apache/drill-site/tree/master/blog/_posts";>existing
posts</a> to see how it's done. When you're ready, email your Markdown file to
<a href="mailto:[email protected]";>[email protected]</a>.</p>
<h1>Third-Party Articles</h1>
<!-- previously: site.posts -->
<p><a class="post-link"
href="https://www.mapr.com/blog/how-turn-raw-data-yelp-insights-minutes-apache-drill";>How
to Turn Raw Data from Yelp into Insights in Minutes with Apache Drill</a> (Nov
13, 2014)<br/></p>
diff --git a/output/zh/docs/apache-drill-contribution-guidelines/index.html
b/output/zh/docs/apache-drill-contribution-guidelines/index.html
index 86f5324..6e85d62 100644
--- a/output/zh/docs/apache-drill-contribution-guidelines/index.html
+++ b/output/zh/docs/apache-drill-contribution-guidelines/index.html
@@ -1526,7 +1526,7 @@ following settings into your browser:</p>
<ol>
<li>The contributor writes the code that addresses a specific JIRA report as
a contribution to the Apache Drill project.</li>
- <li>The contributor organizes (squashes) their code into commits that
segregate out refactoring/reorg, as necessary, to enable efficient review. The
following list identifies how to combine code into commits:<br />
+ <li>The contributor organizes (squashes) their code into commits that
segregate out refactoring/reorg, as necessary, to enable efficient review. The
following list identifies how to combine code into commits:
* Combine WIP and other small commits together.
* Address multiple JIRAs, for smaller bug fixes or enhancements, with a
single commit.
* Use separate commits to allow efficient review, separating out
formatting changes or simple refactoring from core changes or additions.
@@ -1546,7 +1546,7 @@ following settings into your browser:</p>
<li>The contributor asks a committer who has experience with the affected
component for review.
This information can be found in the <a
href="https://issues.apache.org/jira/browse/DRILL/?selectedTab=com.atlassian.jira.jira-projects-plugin:components-panel";>component
owners</a> section of JIRA, or by running <code class="language-plaintext
highlighter-rouge">git blame</code> on the primary files changed in the pull
request. For pull requests that affect multiple areas, send a message to the
dev list to find a reviewer.</li>
<li>The contributor sets the Reviewer field to the assigned reviewer and
marks the status as REVIEWABLE.</li>
- <li>The reviewer reviews the pull request in GitHub and adds comments or a
+1 to the general discussion if the pull request is ready to commit.<br />
+ <li>The reviewer reviews the pull request in GitHub and adds comments or a
+1 to the general discussion if the pull request is ready to commit.
* If there are issues to address, the reviewer changes the JIRA status to
“In Progress.”
* If the reviewer gives a +1, the reviewer adds a “ready-to-commit” label
to the Labels field in the Jira. The contributor should continue to step 9 in
this process.</li>
<li>The contributor addresses review comments. This can be done with new
commits on the branch or with work made on the branch locally, squashed into
the commit(s) posted in the original pull request and force pushed to the
branch the pull request is based on.</li>
@@ -1556,8 +1556,8 @@ This information can be found in the <a
href="https://issues.apache.org/jira/bro
* If the master branch has moved forward since the review, rebase the
branch from the pull request on the latest master and re-run tests.
* If all tests pass, the committer amends the last commit message in the
series to include “this closes #1234”, where 1234 is the pull request number,
not the JIRA number. This can be done with interactive rebase. When on the
branch issue:</p>
- <div class="language-plaintext highlighter-rouge"><div
class="highlight"><pre class="highlight"><code> git rebase -i HEAD^
-* Change where it says “pick” on the line with the last commit, replacing it
with “r” or “reword”. It replays the commit giving you the opportunity the
change the commit message.
+ <div class="language-plaintext highlighter-rouge"><div
class="highlight"><pre class="highlight"><code> git rebase -i HEAD^
+* Change where it says “pick” on the line with the last commit, replacing it
with “r” or “reword”. It replays the commit giving you the opportunity the
change the commit message.
* The committer pushes the commit(s) to the Apache repo (the GitHub repo is
just a read-only mirror).
* The committer resolves the JIRA with a message like `"Fixed in <Git
commit SHA>"`.
</code></pre></div> </div>
@@ -1579,7 +1579,7 @@ This information can be found in the <a
href="https://issues.apache.org/jira/bro
<p>After getting the source code, building and running a few simple queries,
one
of the simplest places to start is to implement a DrillFunc. DrillFuncs are
the way that Drill expresses all scalar functions (UDF or system).</p>
-<p>First you can put together a JIRA for one of the DrillFuncs that we don’t
yet have, but should (referencing the capabilities of something like
Postgres<br />
+<p>First you can put together a JIRA for one of the DrillFuncs that we don’t
yet have, but should (referencing the capabilities of something like Postgres
or SQL Server). Then try to implement one.</p>
<p>See this example DrillFunc:</p>
@@ -1613,12 +1613,12 @@ this history of the discussion.</p>
<li>HOWTOs for using Drill with other popular software.</li>
</ol>
-<p>Documentation committed into the <code class="language-plaintext
highlighter-rouge">gh-pages</code> branch does not have any effect on the Drill
code base and so does not require a JIRA ticket or a corresponding PR from a
repo fork. It does still require a Drill committer to check it and push it
into the Drill code repo. This means</p>
+<p>Documentation committed to the apache/drill-site repository doesn’t have
any effect on the Drill code base and so does not require a JIRA ticket. It
does still require a Drill committer to check it and push it into the Drill
code repo. This means</p>
<ol>
- <li>Drill committers can add documentation with little bureaocratic
overhead.</li>
+ <li>Drill committers can add documentation with little bureaucratic
overhead.</li>
<li>Anyone can send documentation to a Drill committer (find us on Slack or
the mailing lists) as
-markdown or plain text and the committer can incorporate it with little
bureaocratic overhead.</li>
+markdown or plain text and the committer can incorporate it with little
bureaucratic overhead.</li>
</ol>
<h3 id="see-also">See Also</h3>
diff --git a/output/zh/feed.xml b/output/zh/feed.xml
index e69ee1b..c0cb1a7 100644
--- a/output/zh/feed.xml
+++ b/output/zh/feed.xml
@@ -6,8 +6,8 @@
</description>
<link>/</link>
<atom:link href="/zh/feed.xml" rel="self" type="application/rss+xml"/>
- <pubDate>Mon, 03 Jan 2022 08:50:01 +0000</pubDate>
- <lastBuildDate>Mon, 03 Jan 2022 08:50:01 +0000</lastBuildDate>
+ <pubDate>Mon, 03 Jan 2022 11:41:13 +0000</pubDate>
+ <lastBuildDate>Mon, 03 Jan 2022 11:41:13 +0000</lastBuildDate>
<generator>Jekyll v3.9.1</generator>
<item>
