Thanks to visit codestin.com
Credit goes to github.com

Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions .gitignore
Original file line number Diff line number Diff line change
@@ -1,3 +1,4 @@
*.bat

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems not relevant to the PR

*.pyc
*.so
*.pyd
Expand Down
27 changes: 10 additions & 17 deletions doc/developers/contributing.rst
Original file line number Diff line number Diff line change
Expand Up @@ -155,22 +155,12 @@ If any of the above seems like magic to you, then look up the `Git documentation
<http://docs.scipy.org/doc/numpy/dev/gitwash/development_workflow.html>`_ on the
web.

If some conflicts arise between your branch and the ``master`` branch, you need
to merge ``master``. The command will be::

$ git merge master

with ``master`` being synchronized with the ``upstream``.

Subsequently, you need to solve the conflicts. You can refer to the `Git
documentation related to resolving merge conflict using the command line
<https://help.github.com/articles/resolving-a-merge-conflict-using-the-command-line/>`_.

.. note::

In the past, the policy to resolve conflicts was to rebase your branch on
``master``. GitHub interface deals with merging ``master`` better than in
the past.
In particular, if some conflicts arise between your branch and the master
branch, you will need to `rebase your branch on master
<http://docs.scipy.org/doc/numpy/dev/gitwash/development_workflow.html#rebasing-on-master>`_.
Please avoid merging master branch into yours. If you did it anyway, you can fix
it following `this example

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe we should link to the scipy article or embed example git commands instead of linking to an issue comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There something with your branch. You are not synchronized. I made changes in PR #8753 and you should not have the previous version here.

<https://github.com/scikit-learn/scikit-learn/pull/7111#issuecomment-249175383>`_.


Contributing pull requests
Expand Down Expand Up @@ -464,7 +454,9 @@ is a corner-stone of the scikit-learn development process. For this
purpose, we use the `nose <http://nose.readthedocs.io/en/latest/>`_

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nose is being phased out in favor of py.test, correct?

package. The tests are functions appropriately named, located in `tests`
subdirectories, that check the validity of the algorithms and the
different options of the code.
different options of the code.

Regression testing is used to identify and validate any code committed to the repository and see if it does not break any existing code. Any changes made to the existing code in repository such as feature enhancements, bug fixes, document changes, hot fixes, config changes or any other changes to the scikit-learn repository are tested using regression tests. During these tests both functional and non-functional areas of the features are tested. Regression testing also ensures that the change being proposed works well with other parts of the software as a whole in an integrated way. Any bug-fix or change in sklearn repository needs a regression test due to the above reasons.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like there should be a more granular explanation of when PRs should be accompanied by tests - e.g. in most cases documentation edits won't need one

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree. I would go with something simpler like:

In addition, a non-regression test should go along each bug-fix to ensure that such
bug will not occur in the future.

In addition, try to not go over 80 characters also in *.rst.


The full scikit-learn tests can be run using 'make' in the root folder.
Alternatively, running 'nosetests' in a folder will run all the tests of
Expand Down Expand Up @@ -1172,3 +1164,4 @@ that implement common linear model patterns.

The :mod:`sklearn.utils.multiclass` module contains useful functions
for working with multiclass and multilabel problems.


Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Useless change.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am confused where did the other changes in the file come from? I did not make those changes.