yetus-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From a.@apache.org
Subject [1/2] yetus git commit: YETUS-162 rename "latest" docs to "in-progress" to reflect their non-release status.
Date Tue, 17 Nov 2015 04:54:46 GMT
Repository: yetus
Updated Branches:
  refs/heads/master bae1ae053 -> 87014f42a


http://git-wip-us.apache.org/repos/asf/yetus/blob/87014f42/asf-site-src/source/documentation/latest/precommit-basic.md
----------------------------------------------------------------------
diff --git a/asf-site-src/source/documentation/latest/precommit-basic.md b/asf-site-src/source/documentation/latest/precommit-basic.md
deleted file mode 100644
index f508047..0000000
--- a/asf-site-src/source/documentation/latest/precommit-basic.md
+++ /dev/null
@@ -1,268 +0,0 @@
-<!---
-  Licensed to the Apache Software Foundation (ASF) under one
-  or more contributor license agreements.  See the NOTICE file
-  distributed with this work for additional information
-  regarding copyright ownership.  The ASF licenses this file
-  to you under the Apache License, Version 2.0 (the
-  "License"); you may not use this file except in compliance
-  with the License.  You may obtain a copy of the License at
-
-    http://www.apache.org/licenses/LICENSE-2.0
-
-  Unless required by applicable law or agreed to in writing,
-  software distributed under the License is distributed on an
-  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-  KIND, either express or implied.  See the License for the
-  specific language governing permissions and limitations
-  under the License.
--->
-
-test-patch
-==========
-
-* [Purpose](#Purpose)
-* [Pre-requisites](#Pre-requisites)
-* [Basic Usage](#Basic_Usage)
-* [Build Tool](#Build_Tool)
-* [Providing Patch Files](#Providing_Patch_Files)
-* [Project-Specific Capabilities](#Project-Specific_Capabilities)
-* [MultiJDK](#MultiJDK)
-* [Docker](#Docker)
-
-# Purpose
-
-As part of Apache Hadoop's commit process, all patches to the source base go through a precommit
test that does some (relatively) light checking to make sure the proposed change does not
break unit tests and/or passes some other prerequisites such as code formatting guidelines.
 This is meant as a preliminary check for committers so that the basic patch is in a known
state and for contributors to know if they have followed the project's guidelines.  This check,
called test-patch, along with a helper program, called smart-apply-patch, may also be used
by individual developers to verify a patch prior to sending to the Apache Hadoop QA systems.
-
-Other projects have adopted a similar methodology after seeing great success in the Apache
Hadoop model.  Some have even gone as far as forking Apache Hadoop's precommit code and modifying
it to meet their project's needs.
-
-One of the key facets of Apache Yetus is to bring together all of these forks under a common
code base to help software development
-as a whole.
-
-
-# Pre-requisites
-
-test-patch and smart-apply-patch are written in bash for maximum portability.  As such, it
mostly assumes the locations of commands to be in the file path. However, in many cases, this
assumption may be overridden via command line options.
-
-For Solaris and Solaris-like operating systems, the default location for the POSIX binaries
is in /usr/xpg4/bin and the default location for the GNU binaries is /usr/gnu/bin.
-
-## Base Requirements
-
-test-patch requires these installed components to execute:
-
-* A project with a supported build tool (ant, gradle, maven, ...)
-* git-based project (and git 1.7.3 or higher installed)
-* bash v3.2 or higher
-* GNU diff
-* GNU patch
-* POSIX awk
-* POSIX grep
-* POSIX sed
-* [curl](http://curl.haxx.se/) command
-* file command
-
-## Optional Requirements
-
-Features are plug-in based and enabled either individually or collectively on the command
line. From there, these are activated based upon tool availability, the languages being tested,
etc.  The external dependencies of plug-ins may have different licensing requirements than
Apache Yetus.
-
-Bug Systems:
-
-* [GitHub](https://github.com/)-based issue tracking
-* [JIRA](https://www.atlassian.com/software/jira)-based issue tracking
-
-Unit Test Formats:
-
-* [JUnit](http://junit.org/)
-* [TAP](https://testanything.org/)
-
-Language Support, Licensing, and more:
-
-* [Apache Creadur Rat](http://creadur.apache.org/rat/) entries in build system
-* [checkstyle](http://checkstyle.sourceforge.net/) entries in build system (ant and maven
only)
-* [FindBugs](http://findbugs.sourceforge.net/) entries in build system and 3.x executables
-* [Perl::Critic](http://perlcritic.com/) installed
-* [pylint](http://www.pylint.org/) installed
-* [rubocop](http://batsov.com/rubocop/) installed
-* [ruby-lint](https://github.com/YorickPeterse/ruby-lint) installed
-* [shellcheck](https://github.com/koalaman/shellcheck) installed, preferably 0.3.6 or higher
-
-# Basic Usage
-
-The first step for a successful deployment is determining which features/plug-ins to enable:
-
-```bash
-$ test-patch.sh --list-plugins
-```
-
-This option will list all of the available plug-ins that are installed in the default location.
 From this list, the specific plug-ins can be enabled:
-
-```bash
-$ test-patch.sh --plugins="ant,maven,shellcheck,xml" <other options>
-```
-
-As a short-cut, every plug-in may be enabled via the special 'all' type:
-
-```bash
-$ test-patch.sh --plugins="all" <other options>
-```
-
-`--plugins` also allows some basic "arithmetic":
-
-```bash
-$ test-patch.sh --plugins="all,-checkstyle,-findbugs" <other options>
-```
-
-This will enable all plug-ins for potential usage, except for checkstyle and findbugs.
-
-**NOTE: The examples in this section will assume that the necessary `--plugins` option has
been set on the command line as appropriate for your particular installation.**
-
-This command will execute basic patch testing against a patch file stored in "filename":
-
-```bash
-$ cd <your repo>
-$ test-patch.sh --dirty-workspace --project=projectname <filename>
-```
-
-The `--dirty-workspace` flag tells test-patch that the repository is not clean and it is
ok to continue.  By default, unit tests are not run since they may take a significant amount
of time.
-
-To do turn them on, we need to provide the --run-tests option:
-
-
-```bash
-$ cd <your repo>
-$ test-patch.sh --dirty-workspace --run-tests <filename>
-```
-
-This is the same command, but now runs the unit tests.
-
-A typical configuration is to have two repositories.  One with the code you are working on
and another, clean repository.  This means you can:
-
-```bash
-$ cd <workrepo>
-$ git diff master > /tmp/patchfile
-$ cd ../<testrepo>
-$ test-patch.sh --basedir=<testrepo> --resetrepo /tmp/patchfile
-```
-
-We used two new options here.  --basedir sets the location of the repository to use for testing.
 --resetrepo tells test patch that it can go into **destructive** mode.  Destructive mode
will wipe out any changes made to that repository, so use it with care!
-
-After the tests have run, there is a directory that contains all of the test-patch related
artifacts.  This is generally referred to as the patchprocess directory.  By default, test-patch
tries to make something off of /tmp to contain this content.  Using the `--patch-dir` option,
one can specify exactly which directory to use.  This is helpful for automated precommit testing
so that Jenkins or other automated workflow system knows where to look to gather up the output.
-
-For example:
-
-```bash
-$ test-patch.sh --jenkins --patch-dir=${WORKSPACE}/patchprocess --basedir=${WORKSPACE}/source
${WORKSPACE}/patchfile
-```
-
-... will trigger test-patch to run in fully automated Jenkins mode, using ${WORKSPACE}/patchprocess
as its scratch space, ${WORKSPACE}/source as the source repository, and ${WORKSPACE}/patchfile
as the name of the patch to test against.
-
-# Build Tool
-
-Out of the box, test-patch is built to use maven.  But what if the project is built using
something else, such as ant?
-
-```bash
-$ test-patch.sh (other options) --build-tool=ant
-```
-
-will tell test-patch to use ant instead of maven to drive the project.
-
-# Providing Patch Files
-
-## JIRA
-
-It is a fairly common practice within the Apache community to use Apache's JIRA instance
to store potential patches.  As a result, test-patch supports providing just a JIRA issue
number.  test-patch will find the *last* attachment, download it, then process it.
-
-For example:
-
-```bash
-$ test-patch.sh (other options) HADOOP-9905
-```
-
-... will process the patch file associated with this JIRA issue.
-
-If the Apache JIRA system is not in use, then override options may be provided on the command
line to point to a different JIRA instance.
-
-```bash
-$ test-patch.sh --jira-issue-re='^PROJECT-[0-9]+$' --jira-base-url='https://example.com/jira'
PROJECT-90
-```
-
-... will process the patch file attached to PROJECT-90 on the JIRA instance located on the
example.com server.
-
-## GITHUB
-
-test-patch has some basic support for Github.  test-patch supports many forms of providing
pull requests to work on:
-
-```bash
-$ test-patch.sh --github-repo=apache/pig 99
-```
-
-or
-
-```bash
-$ test-patch.sh https://github.com/apache/pig/pulls/99
-```
-
-or
-
-```bash
-$ test-patch.sh https://github.com/apache/pig/pulls/99.patch
-```
-
-... will process PR #99 on the apache/pig repo.
-
-## Generic URLs
-
-Luckily, test-patch supports  provide ways to provide unified diffs via URLs.
-
-For example:
-
-```bash
-$ test-patch.sh (other options) https://example.com/webserver/file.patch
-```
-
-... will download and process the file.patch from the example.com webserver.
-
-# Project-specific Capabilities
-
-Due to the extensible nature of the system, test-patch allows for projects to define project-specific
rules which we call personalities.  (How to build those rules is covered elsewhere.) There
are two ways to specify which personality to use:
-
-## Direct Method
-
-```bash
-$ test-patch.sh (other options) --personality=(filename)
-```
-
-This tells test-patch to use the personality in the given file.
-
-## Project Method
-
-However, test-patch can detect if it is a personality that is in its "personality" directory
based upon the project name:
-
-```bash
-$ test-patch.sh (other options) --project=(project)
-```
-
-# MultiJDK
-
-For many projects, it is useful to test Java code against multiple versions of JDKs at the
same time.  test-patch can do this with the --multijdkdirs option:
-
-```bash
-$ test-patch.sh (other options) --multijdkdirs="/j/d/k/1,/j/d/k/2"
-```
-
-Not all Java tests support this mode, but those that do will now run their tests with all
of the given versions of Java consecutively (e.g., javac--the Java compliation test).  Tests
that do not support MultiJDK mode (e.g., checkstyle, mvn install) will use JAVA\_HOME.
-
-NOTE: JAVA\_HOME is always appended to the list of JDKs in MultiJDK mode.  If JAVA\_HOME
is in the list, it will be moved to the end.
-
-# Docker
-
-test-patch also has a mode to utilize Docker:
-
-```bash
-$ test-patch.sh (other options) --docker
-```
-
-This will do some preliminary setup and then re-execute itself inside a Docker container.
 For more information on how to provide a custom Dockerfile, see the advanced guide.
-
-## In Closing
-
-test-patch has many other features and command line options for the basic user.  Many of
these are self-explanatory.  To see the list of options, run test-patch.sh without any options
or with --help.

http://git-wip-us.apache.org/repos/asf/yetus/blob/87014f42/asf-site-src/source/documentation/latest/precommit-bugsystems.md
----------------------------------------------------------------------
diff --git a/asf-site-src/source/documentation/latest/precommit-bugsystems.md b/asf-site-src/source/documentation/latest/precommit-bugsystems.md
deleted file mode 100644
index 95bf1de..0000000
--- a/asf-site-src/source/documentation/latest/precommit-bugsystems.md
+++ /dev/null
@@ -1,87 +0,0 @@
-<!---
-  Licensed to the Apache Software Foundation (ASF) under one
-  or more contributor license agreements.  See the NOTICE file
-  distributed with this work for additional information
-  regarding copyright ownership.  The ASF licenses this file
-  to you under the Apache License, Version 2.0 (the
-  "License"); you may not use this file except in compliance
-  with the License.  You may obtain a copy of the License at
-
-    http://www.apache.org/licenses/LICENSE-2.0
-
-  Unless required by applicable law or agreed to in writing,
-  software distributed under the License is distributed on an
-  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-  KIND, either express or implied.  See the License for the
-  specific language governing permissions and limitations
-  under the License.
--->
-
-Bug System Support
-==================
-
-test-patch has the ability to support multiple bug systems.  Bug tools have some extra hooks
to fetch patches, line-level reporting, and posting a final report. Every bug system plug-in
must have one line in order to be recognized:
-
-```bash
-add_bugsystem <pluginname>
-```
-
-* pluginname\_locate\_patch
-
-    - Given input from the user, download the patch if possible.
-
-* pluginname\_determine\_branch
-
-    - Using any heuristics available, return the branch to process, if possible.
-
-* pluginname\_determine\_issue
-
-    - Using any heuristics available, set the issue, bug number, etc, for this bug system,
if possible.  This is typically used to fill in supplementary information in the final output
table.
-
-* pluginname\_write\_comment
-
-    - Given text input, write this output to the bug system as a comment.  NOTE: It is the
bug system's responsibility to format appropriately.
-
-* pluginname\_linecomments
-
-    - This function allows for the system to write specific comments on specific lines if
the bug system supports code review comments.
-
-* pluginname\_finalreport
-
-    - Write the final result table to the bug system.
-
-# Bugzilla Specific
-
-Currently, Bugzilla support is read-only.  To use it, the Bug ID must be preferenced with
'BZ:'.  For example:
-
-```bash
-$ test-patch.sh (other options) BZ:4
-```
-
-... will pull down Bugzilla ID #4.
-
-Using the `--bugzilla-base-url` on the command line or BUGZILLA\_BASE\_URL in a project's
personality will define the location of the Bugzilla instance.  By default, it is https://bz.apache.org/bugzilla
.
-
-# GitHub Specific
-
-GitHub supports the full range of functionality, including putting comments on individual
lines.  Be aware, however, that test-patch.sh will require that GitHub PRs be fully rebased
(i.e., a single commit) in many circumstances.
-
-By default, the GitHub plug-in assumes that https://github.com is the base URL for GitHub.
 Enterprise users may override this with the `--github-base-url` for the normal web user interface
and `--github-api-url` for the API URL.  Personalities may use GITHUB\_API\_URL and GITHUB\_BASE\_URL.
-
-The specific repository on GitHub is defined with either `--github-repo` on the command line
or GITHUB\_REPO in a personality.  It should take the form of "user/repo".
-
-In order to comment on issues or, depending upon the security setup of the repo, authentication
credentials.  The GitHub plug-in supports two types:
-
-  * Token-based:  `--github-token` or GITHUB\_TOKEN
-
-  * Username/password: `--github-user`/ GITHUB\_USER , `--github-password` / GITHUB\_PASSWD
-
-Pull requests that are made off of a specific branch will switch the test repo to that branch,
if permitted.  If the pull request references a JIRA issue that matches the given JIRA issue
regexp in the Subject, the JIRA plug-in will also be invoked as needed.
-
-# JIRA Specific
-
-JIRA support allows both patch downloads and summary writes.  It also supports branch detection-based
upon the name of the attached patch file.
-
-JIRA issues are invoked by matching the command line option to a specific regular expression
as given by the `--jira-issue-re` option or via the JIRA\_ISSUE\_RE personality variable.
 By default, the plug-in uses https://issues.apache.org/jira as the JIRA instance to use.
 However that may be overwritten via the `--jira-base-url` option or personalities may define
via JIRA\_URL.
-
-In order to write information on the issue, JIRA requires username and password authentication
using the `--jira-user`/`--jira-password` options or the JIRA\_USER and JIRA\_PASSWORD variables
in a personality.

http://git-wip-us.apache.org/repos/asf/yetus/blob/87014f42/asf-site-src/source/documentation/latest/precommit-buildtools.md
----------------------------------------------------------------------
diff --git a/asf-site-src/source/documentation/latest/precommit-buildtools.md b/asf-site-src/source/documentation/latest/precommit-buildtools.md
deleted file mode 100644
index 923bb86..0000000
--- a/asf-site-src/source/documentation/latest/precommit-buildtools.md
+++ /dev/null
@@ -1,131 +0,0 @@
-<!---
-  Licensed to the Apache Software Foundation (ASF) under one
-  or more contributor license agreements.  See the NOTICE file
-  distributed with this work for additional information
-  regarding copyright ownership.  The ASF licenses this file
-  to you under the Apache License, Version 2.0 (the
-  "License"); you may not use this file except in compliance
-  with the License.  You may obtain a copy of the License at
-
-    http://www.apache.org/licenses/LICENSE-2.0
-
-  Unless required by applicable law or agreed to in writing,
-  software distributed under the License is distributed on an
-  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-  KIND, either express or implied.  See the License for the
-  specific language governing permissions and limitations
-  under the License.
--->
-
-Build Tool Support
-===================
-
-test-patch has the ability to support multiple build tools.  Build tool plug-ins have some
extra hooks to do source and object maintenance at key points. Every build tool plug-in must
have one line in order to be recognized:
-
-```bash
-add_build_tool <pluginname>
-```
-
-# Global Variables
-
-* BUILDTOOLCWD
-
-    - If the build tool does not always run from the ${BASEDIR} and instead needs to change
the current working directory to work on a specific module, then set this to true.  The default
is false.
-
-* UNSUPPORTED\_TEST
-
-    - If pluginname\_modules\_worker is given a test type that is not supported by the build
system, set UNSUPPORTED\_TEST=true.  If it is supported, set UNSUPPORTED\_TEST=false.
-
-For example, the gradle build tool does not have a standard way to execute checkstyle. So
when checkstyle is requested, gradle\_modules\_worker sets UNSUPPORTED\_TEST to true and returns
out of the routine.
-
-# Required Functions
-
-* pluginname\_buildfile
-
-    - This should be an echo of the file that controls the build system.  This is used for
module determination. If the build system wishes to disable module determination, it should
echo with no args.
-
-* pluginname\_executor
-
-    - This should be an echo of how to run the build tool, any extra arguments, etc.
-
-* pluginname\_modules\_worker
-
-    - Input is the branch and the test being run.  This should call `modules_workers` with
the generic parts to run that test on the build system.  For example, if it is convention
to use 'test' to trigger 'unit' tests, then `module_workers` should be called with 'test'
appended onto its normal parameters.
-
-* pluginname\_builtin_personality\_modules
-
-    - Default method to determine how to enqueue modules for processing.  Note that personalities
may override this function.
-
-* pluginname\_builtin_personality\_file\_tests
-
-    - Default method to determine which tests to trigger.  Note that personalities may override
this function.
-
-# Optional Functions
-
-* pluginname\_postapply\_install
-
-    - After the install step, this allows the build tool plug-in to do extra work.
-
-* pluginname\_parse\_args
-
-    - executed prior to any other above functions except for pluginname\_usage. This is useful
for parsing the arguments passed from the user and setting up the execution environment.
-
-* pluginname\_initialize
-
-    - After argument parsing and prior to any other work, the initialize step allows a plug-in
to do any precursor work, set internal defaults, etc.
-
-* pluginname\_count\_(test)\_probs
-
-    - Certain language test plug-ins require assistance from the build tool to count problems
in the compile log due to some tools having custom handling for those languages.  The test
plug-in name should be in the (test) part of the function name.
-
-* pluginname\_docker\_support
-
-    - If this build tool requires extra settings on the `docker run` command line, this function
should be defined and write those options into a file called `${PATCH_DIR}/buildtool-docker-params.txt`.
 This is particularly useful for things like mounting volumes for repository caches.
-
-       **WARNING**: Be aware that directories that do not exist MAY be created by root by
Docker itself under certain conditions.  It is HIGHLY recommend that `pluginname_initialize`
be used to create the necessary directories prior to be used in the `docker run` command.
-
-# Ant Specific
-
-## Command Arguments
-
-test-patch always passes -noinput to Ant.  This forces ant to be non-interactive.
-
-## Docker Mode
-
-In Docker mode, the `${HOME}/.ivy2` directory is shared amongst all invocations.
-
-# Gradle Specific
-
-The gradle plug-in always rebuilds the gradlew file and uses gradlew as the method to execute
commands.
-
-In Docker mode, the `${HOME}/.gradle` directory is shared amongst all invocations.
-
-# Maven Specific
-
-## Command Arguments
-
-test-patch always passes --batch-mode to maven to force it into non-interactive mode.  Additionally,
some tests will also force -fae in order to get all of messages/errors during that mode. Some
tests are executed with -DskipTests.  Additional arguments should be handled via the personality.
-
-##  Per-instance Repositories
-
-Under many common configurations, maven (as of 3.3.3 and lower) may not properly handle being
executed by multiple processes simultaneously, especially given that some tests require the
`mvn install` command to be used.
-
-To assist, `test-patch` supports a `--mvn-custom-repo` option to set the `-Dmaven.repo.local`
value to a per-instance repository directory keyed to the project and branch being used for
the test.  If the `--jenkins` flag is also passed, the instance will be tied to the Jenkins
`${EXECUTOR_NUMBER}` value.  Otherwise, the instance value will be randomly generated via
`${RANDOM}`.  If the repository has not been used in 30 days, it will be automatically deleted
when any test run for that project (regardless of branch!).
-
-By default, `test-patch` uses `${HOME}/yetus-m2` as the base directory to store these custom
maven repositories.  That location may be changed via the `--mvn-custom-repos-dir` option.
-
-The location of the `settings.xml` may be changed via the `--mvn-settings` option.
-
-## Docker Mode
-
-In Docker mode, `${HOME}/.m2` is shared amongst all invocations.  If `--mvn-custom-repos`
is used, all of `--mvn-custom-repos-dir` is shared with all invocations.  The per-instance
directory will be calculated and configured after Docker has launched.
-
-## Test Profile
-
-By default, test-patch will pass -Ptest-patch to Maven. This will allow you to configure
special actions that should only happen when running underneath test-patch.
-
-## Custom Maven Tests
-
-* Maven will trigger a maven install as part of the precompile.
-* Maven will test eclipse integration as part of the postcompile.
-* If src/site is modified, maven site tests are executed.

http://git-wip-us.apache.org/repos/asf/yetus/blob/87014f42/asf-site-src/source/documentation/latest/precommit-glossary.md
----------------------------------------------------------------------
diff --git a/asf-site-src/source/documentation/latest/precommit-glossary.md b/asf-site-src/source/documentation/latest/precommit-glossary.md
deleted file mode 100644
index acf5b23..0000000
--- a/asf-site-src/source/documentation/latest/precommit-glossary.md
+++ /dev/null
@@ -1,42 +0,0 @@
-<!---
-  Licensed to the Apache Software Foundation (ASF) under one
-  or more contributor license agreements.  See the NOTICE file
-  distributed with this work for additional information
-  regarding copyright ownership.  The ASF licenses this file
-  to you under the Apache License, Version 2.0 (the
-  "License"); you may not use this file except in compliance
-  with the License.  You may obtain a copy of the License at
-
-    http://www.apache.org/licenses/LICENSE-2.0
-
-  Unless required by applicable law or agreed to in writing,
-  software distributed under the License is distributed on an
-  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-  KIND, either express or implied.  See the License for the
-  specific language governing permissions and limitations
-  under the License.
--->
-
-# Glossary
-
-## Generic/outside definitions:
-
-Apache's [new contributor documentation](https://community.apache.org/contributors/) and
Maven's [glossary](https://maven.apache.org/glossary.html) are great places to start if you
are new to Apache or Maven.
-
-* Module
-
-  Almost the same meaning as "sub-project" on Maven.
-
-## test-patch specific
-
-* Personality
-
-  A chunk of shell code that tells test-patch this particular project's needs and special
requirements
-
-* Plug-ins
-
-  Shell code snippets that define new, not built-in test types.
-
-* Precommit
-
-  An automated process that verifies a patch is "good" prior to a committer looking at it.

http://git-wip-us.apache.org/repos/asf/yetus/blob/87014f42/asf-site-src/source/documentation/latest/precommit-patchnames.md
----------------------------------------------------------------------
diff --git a/asf-site-src/source/documentation/latest/precommit-patchnames.md b/asf-site-src/source/documentation/latest/precommit-patchnames.md
deleted file mode 100644
index f976b0b..0000000
--- a/asf-site-src/source/documentation/latest/precommit-patchnames.md
+++ /dev/null
@@ -1,37 +0,0 @@
-<!---
-  Licensed to the Apache Software Foundation (ASF) under one
-  or more contributor license agreements.  See the NOTICE file
-  distributed with this work for additional information
-  regarding copyright ownership.  The ASF licenses this file
-  to you under the Apache License, Version 2.0 (the
-  "License"); you may not use this file except in compliance
-  with the License.  You may obtain a copy of the License at
-
-    http://www.apache.org/licenses/LICENSE-2.0
-
-  Unless required by applicable law or agreed to in writing,
-  software distributed under the License is distributed on an
-  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-  KIND, either express or implied.  See the License for the
-  specific language governing permissions and limitations
-  under the License.
--->
-
-We use Apache Yetus to process your patch. It supports the following patterns and
-procedures for patch file names:
-
-JIRA:
-
-If JIRA support is configured, attach the patch to the given ISSUE and
-click 'Submit Patch'.  The patch file should be named one of:
-
-  * ISSUE.patch
-  * ISSUE.###.patch
-  * ISSUE.branch.###.patch
-  * ISSUE-branch-###.patch
-  * ISSUE.##.branch.patch
-  * ISSUE-branch.##.patch
-
-If Github support is also configured, a comment that contains a link to a Pull Request's
-patch file (e.g., https://github.com/user/repo/pull/1.patch) will pull the patch from
-the given Github PR.

http://git-wip-us.apache.org/repos/asf/yetus/blob/87014f42/asf-site-src/source/documentation/latest/precommit-smart-apply-patch.md
----------------------------------------------------------------------
diff --git a/asf-site-src/source/documentation/latest/precommit-smart-apply-patch.md b/asf-site-src/source/documentation/latest/precommit-smart-apply-patch.md
deleted file mode 100644
index 74dc0c3..0000000
--- a/asf-site-src/source/documentation/latest/precommit-smart-apply-patch.md
+++ /dev/null
@@ -1,51 +0,0 @@
-<!---
-  Licensed to the Apache Software Foundation (ASF) under one
-  or more contributor license agreements.  See the NOTICE file
-  distributed with this work for additional information
-  regarding copyright ownership.  The ASF licenses this file
-  to you under the Apache License, Version 2.0 (the
-  "License"); you may not use this file except in compliance
-  with the License.  You may obtain a copy of the License at
-
-    http://www.apache.org/licenses/LICENSE-2.0
-
-  Unless required by applicable law or agreed to in writing,
-  software distributed under the License is distributed on an
-  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-  KIND, either express or implied.  See the License for the
-  specific language governing permissions and limitations
-  under the License.
--->
-
-smart-apply-patch
-=================
-
-`smart-apply-patch` is a command to help apply patches easily.  It uses the same plug-ins
and many of the same options as test-patch.  This means that it can, for example, fetch patches
from JIRA and apply them to a local source tree.
-
-# Usage
-
-Its simpliest form is used when a patch is stored in a local file:
-
-```bash
-$ smart-apply-patch patch
-```
-
-This will cause the command to run through various ways to verify and then apply the patch
to the current repo, including deducing a patch level.
-
-Perhaps you just want to see if the patch even applies without changing your local repo.
 The `--dry-run` option will just test for applicability:
-
-```bash
-$ smart-apply-patch --dry-run patch
-```
-
-For committers of projects, there is a special mode:
-
-```bash
-$ smart-apply-patch --committer patch
-```
-
-that in addition to applying the patch will also attempt to:
-
-* use `--whitespace=fix` mode
-* add all newly created files in the repo
-* use `--signoff` and commit the change via git-am

http://git-wip-us.apache.org/repos/asf/yetus/blob/87014f42/asf-site-src/source/documentation/latest/precommit-testformats.md
----------------------------------------------------------------------
diff --git a/asf-site-src/source/documentation/latest/precommit-testformats.md b/asf-site-src/source/documentation/latest/precommit-testformats.md
deleted file mode 100644
index 41dbb11..0000000
--- a/asf-site-src/source/documentation/latest/precommit-testformats.md
+++ /dev/null
@@ -1,35 +0,0 @@
-<!---
-  Licensed to the Apache Software Foundation (ASF) under one
-  or more contributor license agreements.  See the NOTICE file
-  distributed with this work for additional information
-  regarding copyright ownership.  The ASF licenses this file
-  to you under the Apache License, Version 2.0 (the
-  "License"); you may not use this file except in compliance
-  with the License.  You may obtain a copy of the License at
-
-    http://www.apache.org/licenses/LICENSE-2.0
-
-  Unless required by applicable law or agreed to in writing,
-  software distributed under the License is distributed on an
-  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-  KIND, either express or implied.  See the License for the
-  specific language governing permissions and limitations
-  under the License.
--->
-
-Test Format Support
-==================
-
-test-patch has the ability to support multiple test formats. Test formats have some extra
hooks to process the output of test tools and write the results to some tables. Every test
format plug-in must have one line in order to be recognized:
-
-```bash
-add_test_format <pluginname>
-```
-
-* pluginname\_process\_tests
-
-    - Given a path to the log file and tested module name, parse that file and store the
test result into global variables and/or files.
-
-* pluginname\_finalize\_results
-
-    - Using the results stored by pluginname\_process\_tests, write them to the test result
table and/or the footer table for reporting.

http://git-wip-us.apache.org/repos/asf/yetus/blob/87014f42/asf-site-src/source/documentation/latest/releasedocmaker.md
----------------------------------------------------------------------
diff --git a/asf-site-src/source/documentation/latest/releasedocmaker.md b/asf-site-src/source/documentation/latest/releasedocmaker.md
deleted file mode 100644
index 2a5f0cd..0000000
--- a/asf-site-src/source/documentation/latest/releasedocmaker.md
+++ /dev/null
@@ -1,134 +0,0 @@
-<!---
-  Licensed to the Apache Software Foundation (ASF) under one
-  or more contributor license agreements.  See the NOTICE file
-  distributed with this work for additional information
-  regarding copyright ownership.  The ASF licenses this file
-  to you under the Apache License, Version 2.0 (the
-  "License"); you may not use this file except in compliance
-  with the License.  You may obtain a copy of the License at
-
-    http://www.apache.org/licenses/LICENSE-2.0
-
-  Unless required by applicable law or agreed to in writing,
-  software distributed under the License is distributed on an
-  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-  KIND, either express or implied.  See the License for the
-  specific language governing permissions and limitations
-  under the License.
--->
-
-releasedocmaker
-===============
-
-* [Purpose](#Purpose)
-* [Basic Usage](#Basic_Usage)
-* [Changing the Header](#Changing_the_Header)
-* [Multiple Versions](#Multiple_Versions)
-* [Unreleased Dates](#Unreleased_Dates)
-* [Lint Mode](#Lint_Mode)
-* [Index Mode](#Index_Mode)
-
-# Purpose
-
-Building changelog information in a form that is human digestible but still containing as
much useful information is difficult.  Many attempts over the years have resulted in a variety
of methods that projects use to solve this problem:
-
-* JIRA-generated release notes from the "Release Notes" button
-* Manually modified CHANGES file
-* Processing git log information
-
-All of these methods have their pros and cons.  Some have issues with accuracy.  Some have
issues with lack of details. None of these methods seem to cover all of the needs of many
projects and are full of potential pitfalls.
-
-In order to solve these problems, releasedocmaker was written to automatically generate a
changelog and release notes by querying Apache's JIRA instance.
-
-# Basic Usage
-
-Minimally, the name of the JIRA project and a version registered in JIRA must be provided:
-
-```bash
-$ releasedocmaker.py --project (project) --version (version)
-```
-
-This will query Apache JIRA, generating two files in a directory named after the given version
in an extended markdown format which can be processed by both mvn site and GitHub.
-
-* CHANGES.(version).md
-
-This is similar to the JIRA "Release Notes" button but is in tabular format and includes
the priority, component, reporter, and contributor fields.  It also highlights Incompatible
Changes so that readers know what to look out for when upgrading. The top of the file also
includes the date that the version was marked as released in JIRA.
-
-
-* RELEASENOTES.(version).md
-
-If your JIRA project supports the release note field, this will contain any JIRA mentioned
in the CHANGES log that is either an incompatible change or has a release note associated
with it.  If your JIRA project does not support the release notes field, this will be the
description field.
-
-For example, to build the release documentation for HBase v1.2.0...
-
-```bash
-$ releasedocmaker.py --project HBASE --version 1.2.0
-```
-
-... will create a 1.2.0 directory and inside that directory will be CHANGES.1.2.0.md and
RELEASENOTES.1.2.0.md .
-
-By default, release notes are expected to be in plain text.  However, you can write them
in markdown if you include a header at the top of your release note:
-
-```xml
-<!-- markdown -->
-remaining text
-```
-
-# Changing the Header
-
-By default, it will use a header that matches the project name.  But that is kind of ugly
and the case may be wrong.  Luckily, the title can be changed:
-
-```bash
-$ releasedocmaker.py --project HBASE --version 1.2.0 --projecttitle "Apache HBase"
-```
-
-Now instead of "HBASE", it will use "Apache HBASE" for some titles and headers.
-
-# Multiple Versions
-
-The script can also generate multiple versions at once, by
-
-```bash
-$ releasedocmaker.py --project HBASE --version 1.0.0 --version 1.2.0
-```
-
-This will create the files for versions 1.0.0 and versions 1.2.0 in their own directories.
-
-But what if the version numbers are not known?  releasedocmaker can also generate version
data based upon ranges:
-
-```bash
-$ releasedocmaker.py --project HBASE --version 1.0.0 --version 1.2.0 --range
-```
-
-In this form, releasedocmaker will query JIRA, discover all versions that alphabetically
appear to be between 1.0.0 and 1.2.0, inclusive, and generate all of the relative release
documents.  This is especially useful when bootstrapping an existing project.
-
-# Unreleased Dates
-
-For released versions, releasedocmaker will pull the date of the release from JIRA.  However,
for unreleased versions it marks the release as "Unreleased". This can be inconvenient when
actually building a release and wanting to include it inside the source package.
-
-The --usetoday option can be used to signify that instead of using Unreleased, releasedocmaker
should use today's date.
-
-```bash
-$ releasedocmaker.py --project HBASE --version 1.0.0 --usetoday
-```
-
-After using this option and release, don't forget to change JIRA's release date to match!
-
-# Lint Mode
-
-In order to ensure proper formatting while using mvn site, releasedocmaker puts in periods
(.) for fields that are empty or unassigned.  This can be unsightly and not proper for any
given project.  There are also other things, such as missing release notes for incompatible
changes, that are less than desirable.
-
-In order to help release managers from having to scan through potentially large documents,
releasedocmaker features a lint mode, triggered via --lint:
-
-```bash
-$ releasedocmaker.py --project HBASE --version 1.0.0 --lint
-```
-
-This will do the normal JIRA querying, looking for items it considers problematic.  It will
print the information to the screen and then exit with either success or failure, depending
upon if any issues were discovered.
-
-# Index Mode
-
-There is basic support for an autoindexer.  It will create two files that contain links to
all directories that have a major.minor.micro-style version numbering system, where all fields
are numeric.
-
-  * index.md: a file suitable for conversion to HTML via mvn site
-  * README.md: a file suitable for display on Github and other Markdown rendering websites


Mime
View raw message