Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Checklist for public release of mitiq #268

Closed
9 of 11 tasks
nathanshammah opened this issue Jul 28, 2020 · 15 comments
Closed
9 of 11 tasks

Checklist for public release of mitiq #268

nathanshammah opened this issue Jul 28, 2020 · 15 comments
Assignees

Comments

@nathanshammah
Copy link
Member

nathanshammah commented Jul 28, 2020

This is a checklist of tasks to do before the repository becomes public. Some are proposals of things that could be implemented or improved and should be discussed, possibly here if on github, take them as ideas:

Needed for Launch

Immediately after open-sourcing


Optional stuff:

  • consider using docker for CI even beyond PyQuil (In a python-only environment this may be an overkill, but certainly it makes everything robust)
  • have guides for contributors and maintainers and possibly autoreleases to pypi, test pypi.
  • consider adding templates for PRs or issues: It would certainly help new contributors, may be cumbersome for UF team. In PRs, it could remind contributors to check code with black.=
  • update the mitiq roadmap on the wiki, see Update Mitiq roadmap on the Wiki #266
@willzeng
Copy link
Contributor

Some comments:

asking folks to check code with black

What does this mean @nathanshammah ?

consider using docker for CI even beyond PyQuil (In a python-only environment this may be an overkill, but certainly it makes everything robust)
consider adding templates for PRs or issues: It would certainly help new contributors, may be cumbersome for UF team.

These IMO are not needed for launch. They can be added later.

have guides for contributors and maintainers and possibly autoreleases to pypi, test pypi.

We have contributor guides already no? @karalekas How much work is it to set up the autoreleases?

@willzeng willzeng added this to the Alpha v4 milestone Jul 28, 2020
@nathanshammah
Copy link
Member Author

@willzeng edited that item to make it more clear:
check code formatting with black or pycodestyle.

@karalekas
Copy link
Member

@willzeng

  • setting up the autoreleases shouldn't take more than a couple of hours -- i'm happy to take that on
  • as for contributor guides, it's probably worth taking a day and combing through the various markdown files in the repo just to make sure they're updated to reflect the latest repo contents, install instructions, etc.
  • re: black / code style -- if we want to use this & enforce in the CI, id recommend doing so before external contributors come in. would only take an hour or so

@karalekas
Copy link
Member

another potential checklist item: type checking with mypy. this is another code quality thing that can be enforced with CI, and is of course easier to implement the sooner you do it. my guess would be about half a day, only because I'd need to understand the QPROGRAM issue (#253)

@karalekas
Copy link
Member

yet another potential checklist item: enforcing code coverage. this can be done using coveralls. we're currently at ~85%, and id bet we could get it over 90% in an hour

Name                                                    Stmts   Miss  Cover
---------------------------------------------------------------------------
mitiq/__init__.py                                           5      0   100%
mitiq/_about.py                                            24     11    54%
mitiq/_typing.py                                           10      2    80%
mitiq/_version.py                                           4      0   100%
mitiq/benchmarks/__init__.py                                0      0   100%
mitiq/benchmarks/maxcut.py                                 45      1    98%
mitiq/benchmarks/random_circuits.py                        44      2    95%
mitiq/benchmarks/randomized_benchmarking.py                20      1    95%
mitiq/benchmarks/tests/test_maxcut.py                      17      0   100%
mitiq/benchmarks/tests/test_random_circuit.py              31      0   100%
mitiq/benchmarks/tests/test_randomized_benchmaking.py      42      0   100%
mitiq/benchmarks/utils.py                                   8      0   100%
mitiq/factories.py                                        224     27    88%
mitiq/folding.py                                          236      8    97%
mitiq/mitiq_pyquil/__init__.py                              0      0   100%
mitiq/mitiq_pyquil/conversions.py                          12     12     0%
mitiq/mitiq_pyquil/pyquil_utils.py                         65     65     0%
mitiq/mitiq_pyquil/quil.py                                 63     63     0%
mitiq/mitiq_pyquil/tests/__init__.py                        0      0   100%
mitiq/mitiq_pyquil/tests/test_conversions.py                0      0   100%
mitiq/mitiq_pyquil/tests/test_quil.py                      23     23     0%
mitiq/mitiq_pyquil/tests/test_zne.py                       38     38     0%
mitiq/mitiq_qiskit/__init__.py                              2      0   100%
mitiq/mitiq_qiskit/conversions.py                          12      0   100%
mitiq/mitiq_qiskit/qiskit_utils.py                         32     19    41%
mitiq/tests/test_factories.py                             174      0   100%
mitiq/tests/test_folding.py                               552      0   100%
mitiq/tests/test_utils.py                                 110      0   100%
mitiq/tests/test_zne.py                                    39      3    92%
mitiq/utils.py                                             19      1    95%
mitiq/zne.py                                               26      0   100%
---------------------------------------------------------------------------
TOTAL                                                    1877    276    85%

@karalekas
Copy link
Member

these two I think are definitely worth doing, even if you choose to pass for now on mypy / coverage stuff:

  • Move the changes.rst to the top-level directory and make it a markdown file. Having a markdown changelog and requiring contributors to add to it when opening a PR is a really great way to let release notes write themselves.
  • Clean up the README -- add some badges, add some color, add a code snippet w/ syntax highlighting, etc. Right now the main attraction is the source tree, which is not very exciting

@nathanshammah
Copy link
Member Author

yet another potential checklist item: enforcing code coverage. this can be done using coveralls. we're currently at ~85%, and id bet we could get it over 90% in an hour

Name                                                    Stmts   Miss  Cover
---------------------------------------------------------------------------
mitiq/__init__.py                                           5      0   100%
mitiq/_about.py                                            24     11    54%
mitiq/_typing.py                                           10      2    80%
mitiq/_version.py                                           4      0   100%
mitiq/benchmarks/__init__.py                                0      0   100%
mitiq/benchmarks/maxcut.py                                 45      1    98%
mitiq/benchmarks/random_circuits.py                        44      2    95%
mitiq/benchmarks/randomized_benchmarking.py                20      1    95%
mitiq/benchmarks/tests/test_maxcut.py                      17      0   100%
mitiq/benchmarks/tests/test_random_circuit.py              31      0   100%
mitiq/benchmarks/tests/test_randomized_benchmaking.py      42      0   100%
mitiq/benchmarks/utils.py                                   8      0   100%
mitiq/factories.py                                        224     27    88%
mitiq/folding.py                                          236      8    97%
mitiq/mitiq_pyquil/__init__.py                              0      0   100%
mitiq/mitiq_pyquil/conversions.py                          12     12     0%
mitiq/mitiq_pyquil/pyquil_utils.py                         65     65     0%
mitiq/mitiq_pyquil/quil.py                                 63     63     0%
mitiq/mitiq_pyquil/tests/__init__.py                        0      0   100%
mitiq/mitiq_pyquil/tests/test_conversions.py                0      0   100%
mitiq/mitiq_pyquil/tests/test_quil.py                      23     23     0%
mitiq/mitiq_pyquil/tests/test_zne.py                       38     38     0%
mitiq/mitiq_qiskit/__init__.py                              2      0   100%
mitiq/mitiq_qiskit/conversions.py                          12      0   100%
mitiq/mitiq_qiskit/qiskit_utils.py                         32     19    41%
mitiq/tests/test_factories.py                             174      0   100%
mitiq/tests/test_folding.py                               552      0   100%
mitiq/tests/test_utils.py                                 110      0   100%
mitiq/tests/test_zne.py                                    39      3    92%
mitiq/utils.py                                             19      1    95%
mitiq/zne.py                                               26      0   100%
---------------------------------------------------------------------------
TOTAL                                                    1877    276    85%

@karalekas, about this: we had a discussion some time back (#122), and neither one of us seemed to know the difference between coveralls and pytest-cov. Are they just the same service, the former wrapped with APIs so that it shows up in the GH PR conversation, the latter more basic? The first one can be more helpful, the second one is less "intrusive". Personally, I am happy to go for it.

@rmlarose
Copy link
Contributor

+1 for coverage and mypy.

@willzeng
Copy link
Contributor

willzeng commented Jul 30, 2020 via email

@karalekas
Copy link
Member

karalekas commented Aug 2, 2020

Added CHANGELOG.md and README.md bullets to the issue description, which we can discuss tomorrow @nathanshammah

@karalekas
Copy link
Member

NB: Once we open-source the repo, we should drop the review-requested/assigned restriction on triggering the build.

@willzeng
Copy link
Contributor

willzeng commented Aug 4, 2020 via email

@willzeng
Copy link
Contributor

@karalekas These are the current usage stats:
image

@willzeng
Copy link
Contributor

#316 checked a box here

@willzeng
Copy link
Contributor

With #330 the needed parts for this issue are checked and so will close this issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants