# SOME DESCRIPTIVE TITLE.
# Copyright (C) 2015, Preferred Networks, inc. and Preferred Infrastructure,
# inc.
# This file is distributed under the same license as the python-pcl package.
# FIRST AUTHOR <EMAIL@ADDRESS>, 2017.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: python-pcl 0.0.1.dev0\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2017-07-28 11:33+0900\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Generated-By: Babel 2.4.0\n"

#: ../../source/contribution.rst:2
msgid "python-pcl Contribution Guide"
msgstr "python-pclRgr[VKCh"

#: ../../source/contribution.rst:4
msgid ""
"This is a guide for all contributions to python-pcl. The development of "
"python-pcl is running on `the official repository at GitHub "
"<https://github.com/strawlab/python-pcl>`_. Anyone that wants to "
"register an issue or to send a pull request should read through this "
"document."
msgstr "̃KCh cpl-python "

#: ../../source/contribution.rst:9
msgid "Classification of Contributions"
msgstr ""

#: ../../source/contribution.rst:11
msgid "There are several ways to contribute to python-pcl community:"
msgstr ""

#: ../../source/contribution.rst:13
msgid "Registering an issue"
msgstr ""

#: ../../source/contribution.rst:14
msgid "Sending a pull request (PR)"
msgstr ""

#: ../../source/contribution.rst:15
msgid ""
"Sending a question to `python-pcl User Group "
"<https://groups.google.com/forum/#!forum/python-pcl>`_"
msgstr ""

#: ../../source/contribution.rst:16
msgid "Writing a post about python-pcl"
msgstr ""

#: ../../source/contribution.rst:18
msgid ""
"This document mainly focuses on 1 and 2, though other contributions are "
"also appreciated."
msgstr ""

#: ../../source/contribution.rst:21
msgid "Release and Milestone"
msgstr ""

#: ../../source/contribution.rst:23
msgid ""
"We are using `GitHub Flow <http://scottchacon.com/2011/08/31/github-"
"flow.html>`_ as our basic working process. In particular, we are using "
"the master branch for our development, and releases are made as tags."
msgstr ""

#: ../../source/contribution.rst:26
msgid ""
"Releases are classified into three groups: major, minor, and revision. "
"This classification is based on following criteria:"
msgstr ""

#: ../../source/contribution.rst:29
msgid ""
"**Major update** contains disruptive changes that break the backward "
"compatibility."
msgstr ""

#: ../../source/contribution.rst:30
msgid ""
"**Minor update** contains additions and extensions to the APIs keeping "
"the supported backward compatibility."
msgstr ""

#: ../../source/contribution.rst:31
msgid ""
"**Revision update** contains improvements on the API implementations "
"without changing any API specification."
msgstr ""

#: ../../source/contribution.rst:33
msgid ""
"The release classification is reflected into the version number x.y.z, "
"where x, y, and z corresponds to major, minor, and revision updates, "
"respectively."
msgstr ""

#: ../../source/contribution.rst:35
msgid ""
"We set a milestone for an upcoming release. The milestone is of name "
"'vX.Y.Z', where the version number represents a revision release at the "
"outset. If at least one *feature* PR is merged in the period, we rename "
"the milestone to represent a minor release (see the next section for the "
"PR types)."
msgstr ""

#: ../../source/contribution.rst:39
msgid "See also :doc:`compatibility`."
msgstr ""

#: ../../source/contribution.rst:42
msgid "Issues and PRs"
msgstr ""

#: ../../source/contribution.rst:44
msgid "Issues and PRs are classified into following categories:"
msgstr ""

#: ../../source/contribution.rst:46
msgid "**Bug**: bug reports (issues) and bug fixes (PRs)"
msgstr ""

#: ../../source/contribution.rst:47
msgid ""
"**Enhancement**: implementation improvements without breaking the "
"interface"
msgstr ""

#: ../../source/contribution.rst:48
msgid "**Feature**: feature requests (issues) and their implementations (PRs)"
msgstr ""

#: ../../source/contribution.rst:49
msgid "**NoCompat**: disrupts backward compatibility"
msgstr ""

#: ../../source/contribution.rst:50
msgid "**Test**: test fixes and updates"
msgstr ""

#: ../../source/contribution.rst:51
msgid "**Document**: document fixes and improvements"
msgstr ""

#: ../../source/contribution.rst:52
msgid "**Example**: fixes and improvements on the examples"
msgstr ""

#: ../../source/contribution.rst:53
msgid "**Install**: fixes installation script"
msgstr ""

#: ../../source/contribution.rst:54
msgid ""
"**Contribution-Welcome**: issues that we request for contribution (only "
"issues are categorized to this)"
msgstr ""

#: ../../source/contribution.rst:55
msgid "**Other**: other issues and PRs"
msgstr ""

#: ../../source/contribution.rst:57
msgid ""
"Issues and PRs are labeled by these categories. This classification is "
"often reflected into its corresponding release category: Feature "
"issues/PRs are contained into minor/major releases and NoCompat "
"issues/PRs are contained into major releases, while other issues/PRs can "
"be contained into any releases including revision ones."
msgstr ""

#: ../../source/contribution.rst:60
msgid ""
"On registering an issue, write precise explanations on what you want pcl-"
"python to be. Bug reports must include necessary and sufficient "
"conditions to reproduce the bugs. Feature requests must include **what** "
"you want to do (and **why** you want to do, if needed). You can contain "
"your thoughts on **how** to realize it into the feature requests, though "
"**what** part is most important for discussions."
msgstr ""

#: ../../source/contribution.rst:67
msgid ""
"If you have a question on usages of python-pcl, it is highly recommended "
"to send a post to `python-pcl User Group "
"<https://groups.google.com/forum/#!forum/python-pcl>`_ instead of the "
"issue tracker. The issue tracker is not a place to share knowledge on "
"practices. We may redirect question issues to python-pcl User Group."
msgstr ""

#: ../../source/contribution.rst:71
msgid ""
"If you can write code to fix an issue, send a PR to the master branch. "
"Before writing your code for PRs, read through the :ref:`coding-guide`. "
"The description of any PR must contain a precise explanation of **what** "
"and **how** you want to do; it is the first documentation of your code "
"for developers, a very important part of your PR."
msgstr ""

#: ../../source/contribution.rst:75
msgid ""
"Once you send a PR, it is automatically tested on `Travis CI <https"
"://travis-ci.org/python-pcl/python-pcl/>`_ for Linux and Mac OS X, and on"
" `AppVeyor <https://ci.appveyor.com/project/python-pcl/python-pcl>`_ for "
"Windows. Your PR need to pass at least the test for Linux on Travis CI. "
"After the automatic test passes, some of the core developers will start "
"reviewing your code. Note that this automatic PR test only includes CPU "
"tests."
msgstr ""

#: ../../source/contribution.rst:82
msgid ""
"We are also running continuous integration with GPU tests for the master "
"branch. Since this service is running on our internal server, we do not "
"use it for automatic PR tests to keep the server secure."
msgstr ""

#: ../../source/contribution.rst:86
msgid ""
"Even if your code is not complete, you can send a pull request as a "
"*work-in-progress PR* by putting the ``[WIP]`` prefix to the PR title. If"
" you write a precise explanation about the PR, core developers and other "
"contributors can join the discussion about how to proceed the PR."
msgstr ""

#: ../../source/contribution.rst:92
msgid "Coding Guidelines"
msgstr ""

#: ../../source/contribution.rst:94
msgid ""
"We use `PEP8 <https://www.python.org/dev/peps/pep-0008/>`_ and a part of "
"`OpenStack Style Guidelines "
"<http://docs.openstack.org/developer/hacking/>`_ related to general "
"coding style as our basic style guidelines."
msgstr ""

#: ../../source/contribution.rst:96
msgid ""
"To check your code, use ``autopep8`` and ``flake8`` command installed by "
"``hacking`` package::"
msgstr ""

#: ../../source/contribution.rst:102
msgid "To check Cython code, use ``.flake8.cython`` configuration file::"
msgstr ""

#: ../../source/contribution.rst:106
msgid ""
"The ``autopep8`` supports automatically correct Python code to conform to"
" the PEP 8 style guide::"
msgstr ""

#: ../../source/contribution.rst:110
msgid ""
"The ``flake8`` command lets you know the part of your code not obeying "
"our style guidelines. Before sending a pull request, be sure to check "
"that your code passes the ``flake8`` checking."
msgstr ""

#: ../../source/contribution.rst:113
msgid ""
"Note that ``flake8`` command is not perfect. It does not check some of "
"the style guidelines. Here is a (not-complete) list of the rules that "
"``flake8`` cannot check."
msgstr ""

#: ../../source/contribution.rst:117
msgid "Relative imports are prohibited. [H304]"
msgstr ""

#: ../../source/contribution.rst:118
msgid "Importing non-module symbols is prohibited."
msgstr ""

#: ../../source/contribution.rst:119
msgid ""
"Import statements must be organized into three parts: standard libraries,"
" third-party libraries, and internal imports. [H306]"
msgstr ""

#: ../../source/contribution.rst:121
msgid ""
"In addition, we restrict the usage of *shortcut symbols* in our code "
"base. They are symbols imported by packages and sub-packages of ``pcl-"
"python``. For example, ``python-pcl.cuda.Device`` is a shortcut of ``pcl-"
"python.cuda.device.Device``. **It is not allowed to use such shortcuts in"
" the ``python-pcl`` library implementation**. Note that you can still use"
" them in ``tests`` and ``examples`` directories."
msgstr ""

#: ../../source/contribution.rst:127
msgid ""
"Once you send a pull request, your coding style is automatically checked "
"by `Travis-CI <https://travis-ci.org/python-pcl/python-pcl/>`_. The "
"reviewing process starts after the check passes."
msgstr ""

#: ../../source/contribution.rst:130
msgid ""
"The python-pcl is designed based on NumPy's API design. python-pcl's "
"source code and documents contain the original NumPy ones. Please note "
"the followings when writing the document."
msgstr ""

#: ../../source/contribution.rst:133
msgid ""
"In order to identify overlapping parts, it is preferable to add some "
"remarks that this document is just copied or altered from the original "
"one. It is also preferable to briefly explain the specification of the "
"function in a short paragraph, and refer to the corresponding function in"
" NumPy so that users can read the detailed document. However, it is "
"possible to include a complete copy of the document with such a remark if"
" users cannot summarize in such a way."
msgstr ""

#: ../../source/contribution.rst:140
msgid ""
"If a function in python-pcl only implements a limited amount of features "
"in the original one, users should explicitly describe only what is "
"implemented in the document."
msgstr ""

#: ../../source/contribution.rst:146
msgid "Testing Guidelines"
msgstr ""

#: ../../source/contribution.rst:148
msgid ""
"Testing is one of the most important part of your code. You must test "
"your code by unit tests following our testing guidelines. Note that we "
"are using the nose package and the mock package for testing, so install "
"nose and mock before writing your code::"
msgstr ""

#: ../../source/contribution.rst:154
msgid ""
"In order to run unit tests at the repository root, you first have to "
"build Cython files in place by running the following command::"
msgstr ""

#: ../../source/contribution.rst:158
msgid ""
"Once the Cython modules are built, you can run unit tests simply by "
"running ``nosetests`` command at the repository root::"
msgstr ""

#: ../../source/contribution.rst:162
msgid ""
"It requires CUDA by default. In order to run unit tests that do not "
"require CUDA, pass ``--attr='!gpu'`` option to the ``nosetests`` "
"command::"
msgstr ""

#: ../../source/contribution.rst:167
msgid ""
"Some GPU tests involve multiple GPUs. If you want to run GPU tests with "
"insufficient number of GPUs, specify the number of available GPUs by "
"``--eval-attr='gpu<N'`` where ``N`` is a concrete integer. For example, "
"if you have only one GPU, launch ``nosetests`` by the following command "
"to skip multi-GPU tests::"
msgstr ""

#: ../../source/contribution.rst:173
msgid ""
"Tests are put into the ``tests/python-pcl_tests`` and "
"``tests/install_tests`` directories. These have the same structure as "
"that of ``python-pcl`` and ``install`` directories, respectively. In "
"order to enable test runner to find test scripts correctly, we are using "
"special naming convention for the test subdirectories and the test "
"scripts."
msgstr ""

#: ../../source/contribution.rst:177
msgid ""
"The name of each subdirectory of ``tests`` must end with the ``_tests`` "
"suffix."
msgstr ""

#: ../../source/contribution.rst:178
msgid "The name of each test script must start with the ``test_`` prefix."
msgstr ""

#: ../../source/contribution.rst:180
msgid ""
"Following this naming convention, you can run all the tests by just "
"typing ``nosetests`` at the repository root::"
msgstr ""

#: ../../source/contribution.rst:184
msgid "Or you can also specify a root directory to search test scripts from::"
msgstr ""

#: ../../source/contribution.rst:189
msgid ""
"If you modify the code related to existing unit tests, you must run "
"appropriate commands."
msgstr ""

#: ../../source/contribution.rst:192
msgid ""
"python-pcl tests include type-exhaustive test functions which take long "
"time to execute. If you are running tests on a multi-core machine, you "
"can parallelize the tests by following options::"
msgstr ""

#: ../../source/contribution.rst:197
msgid ""
"The magic numbers can be modified for your usage. Note that some tests "
"require many CUDA compilations, which require a bit long time. Without "
"the ``process-timeout`` option, the timeout is set shorter, causing "
"timeout failures for many test cases."
msgstr ""

#: ../../source/contribution.rst:201
msgid ""
"There are many examples of unit tests under the ``tests`` directory. They"
" simply use the ``unittest`` package of the standard library."
msgstr ""

#: ../../source/contribution.rst:204
msgid ""
"Even if your patch includes GPU-related code, your tests should not fail "
"without GPU capability. Test functions that require CUDA must be tagged "
"by the ``python-pcl.testing.attr.gpu``::"
msgstr ""

#: ../../source/contribution.rst:217
msgid ""
"The functions tagged by the ``gpu`` decorator are skipped if "
"``--attr='!gpu'`` is given. We also have the ``pcl-"
"python.testing.attr.cudnn`` decorator to let ``nosetests`` know that the "
"test depends on cuDNN."
msgstr ""

#: ../../source/contribution.rst:220
msgid ""
"The test functions decorated by ``gpu`` must not depend on multiple GPUs."
" In order to write tests for multiple GPUs, use ``pcl-"
"python.testing.attr.multi_gpu()`` or ``pcl-"
"python.testing.attr.multi_gpu()`` decorators instead::"
msgstr ""

#: ../../source/contribution.rst:233
msgid ""
"Once you send a pull request, your code is automatically tested by "
"`Travis-CI <https://travis-ci.org/python-pcl/python-pcl/>`_ **with "
"--attr='!gpu,!slow' option**. Since Travis-CI does not support CUDA, we "
"cannot check your CUDA-related code automatically. The reviewing process "
"starts after the test passes. Note that reviewers will test your code "
"without the option to check CUDA-related code."
msgstr ""

#: ../../source/contribution.rst:239
msgid ""
"Some of numerically unstable tests might cause errors irrelevant to your "
"changes. In such a case, we ignore the failures and go on to the review "
"process, so do not worry about it."
msgstr ""