-
-
Notifications
You must be signed in to change notification settings - Fork 163
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
Comments
Some comments:
What does this mean @nathanshammah ?
These IMO are not needed for launch. They can be added later.
We have contributor guides already no? @karalekas How much work is it to set up the autoreleases? |
@willzeng edited that item to make it more clear: |
|
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 |
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
|
these two I think are definitely worth doing, even if you choose to pass for now on mypy / coverage stuff:
|
@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. |
+1 for coverage and mypy. |
+1 for coverage and mypy
…On Wed, Jul 29, 2020, 5:31 PM Ryan LaRose ***@***.***> wrote:
+1 for coverage and mypy.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#268 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABHZDAS3UTGPSELCXLVD6HTR6CIMTANCNFSM4PKZQRLA>
.
|
Added |
NB: Once we open-source the repo, we should drop the review-requested/assigned restriction on triggering the build. |
This is a good point. What should we replace it with? We’ll still want to
be conservative about eating up too much of our cloud compute github time.
On Mon, Aug 3, 2020 at 13:10 Peter Karalekas ***@***.***> wrote:
NB: Once we open-source the repo, we should drop the
review-requested/assigned restriction on triggering the build.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#268 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABHZDAXNEJP6IRQ5HJ54XC3R63VRVANCNFSM4PKZQRLA>
.
--
https://unitary.fund/
Creating a quantum technology ecosystem that benefits the most people.
|
@karalekas These are the current usage stats: |
#316 checked a box here |
With #330 the needed parts for this issue are checked and so will close this issue |
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
CHANGELOG.md
README.md
(Update readme #330 )mypy
(see also: Mypy is pretty upset with the QPROGRAM type #253)Immediately after open-sourcing
Optional stuff:
The text was updated successfully, but these errors were encountered: