+ license is OK (ASL 2.0)
+ license file is present, %license is used
+ latest version (git snapshot)
+ new python template is used
- provides and requires look fine
Some tests are skipped with because statsmodels is missing. We have statsmodels packaged, consider adding it to BR and Recommends.

+ no scriptlets
+ check is present and tests pass
- the tests run unparallized. It would be nice to make them parallel, because the tests are the slowest thing when building.

Tests fail with:
======================================================================
FAIL: pymc3.tests.test_stats.test_dic_warns_on_transformed_rv
Test that deviance information criterion calculation warns when an RV is transformed
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.5/site-packages/nose/case.py", line 198, in runTest
    self.test(*self.arg)
  File "/builddir/build/BUILD/pymc3-7427adb98c3fc6a7617415e9309c2bf0dc80d8bb/pymc3/tests/test_stats.py", line 62, in test_dic_warns_on_transformed_rv
    assert(len(w) == 1)
AssertionError: 
-------------------- >> begin captured stdout << ---------------------
[-----------------100%-----------------] 100 of 100 complete in 0.0 sec

--------------------- >> end captured stdout << ----------------------

----------------------------------------------------------------------
Ran 594 tests in 2785.901s

FAILED (failures=1, skipped=12)

> the tests run unparallized
have no idea how to do this...

> Tests fail with:
If I will add some sleep between py2 and py3 tests it will work, dont know why.

(In reply to Igor Gnatenko from comment #2)
> > the tests run unparallized
> have no idea how to do this...

I tried experimenting with nosetests --processes=<n> parameter, but it doesn't seem to work. Running tests in parallel requires some support, so it would probably be best handled upstream.

Filed https://github.com/pymc-devs/pymc3/issues/889.

> > Tests fail with:
> If I will add some sleep between py2 and py3 tests it will work, dont know
> why.

Let's see what happens in koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=12168920.

zbyszek's scratch build of python-pymc3-3.0-0.1.git7427adb.fc24.src.rpm for rawhide failed http://koji.fedoraproject.org/koji/taskinfo?taskID=12168920

My review is yet unofficial as I am not part of the packager group.

I have three remarks one the spec file.

1. Can you condition the py3 related actions (subpackages, build, install, %files) ? This way we can use the same spec file on Fedora with python3 support, and EL7 with no python3 support.

Using something like the following :

> %if 0%{?fedora}
> %global with_python3 1
> %endif
>
> %if 0%{?with_python3}
> %py3_build
> %endif

2. Upstream provides several files that should go in a %doc in the %files section but they are not currently listed. I am thinking about 

 * changelog.md
 * readme.md
 * release-notes.md

3. Upstream provides a way to generate a complete documentation[1], a -doc subpackage might be a good idea to provide it for the end user.

[1] https://github.com/pymc-devs/pymc3/blob/master/howto_docs.md

(In reply to Yanis Guenane from comment #5)
> 1. Can you condition the py3 related actions (subpackages, build, install,
> %files) ? This way we can use the same spec file on Fedora with python3
> support, and EL7 with no python3 support.
> 
> Using something like the following :
> 
> > %if 0%{?fedora}
> > %global with_python3 1
> > %endif
> >
> > %if 0%{?with_python3}
> > %py3_build
> > %endif

What you propose is useful, but OTOH, there is little reason to
introduce this until the EPEL package actually happens. It is quite
likely that this package will never be built for EPEL, and then this
is wasted effort. If the need ever arises to add this, those
conditionals can be added in the exact same way.

> 2. Upstream provides several files that should go in a %doc in the %files
> section but they are not currently listed. I am thinking about 
> 
>  * changelog.md
>  * readme.md
>  * release-notes.md
> 
> 3. Upstream provides a way to generate a complete documentation[1], a -doc
> subpackage might be a good idea to provide it for the end user.
> 
> [1] https://github.com/pymc-devs/pymc3/blob/master/howto_docs.md

Agreed with the other two comments.

... so, what's the plan here? I guess that parallelized tests are not possible now. There are a few issues raised in comments #1 and #5. Can you fix/reject those and make a new version?

Unfortunately I don't have time to work on these review requests anymore, sorry.