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

Outside contributor would not know how to start #184

Open
yosefm opened this issue Sep 6, 2019 · 2 comments
Open

Outside contributor would not know how to start #184

yosefm opened this issue Sep 6, 2019 · 2 comments
Assignees

Comments

@yosefm
Copy link
Member

yosefm commented Sep 6, 2019

README files are outdatd, at least regarding tests and build process. Trying to run "make verify" as the README instructs can take up an hour before you find (by asking an active developer) that the tests are now all done through py_bind. If one has to ask, you already lost 90% of potential contributors. They wouldn't ask, they'll just go away. Just like with the installation.

@alexlib alexlib self-assigned this Sep 7, 2019
@alexlib
Copy link
Contributor

alexlib commented Sep 7, 2019

@yosefm - I find this page in a reasonable condition
https://github.com/OpenPTV/openptv

and it points to the documentation on readthedocs.

do you think it is necessary to keep also https://github.com/OpenPTV/openptv/blob/master/liboptv/README.txt

that is not in sync with the documentation?

I think it'll be more reasonable to remove all README files or point from each one of them to the same central documentation?

I think this question relates to the main one: do we keep liboptv compilation and readiness for C interface or we are fine with C code being just a Python binded and tested?

What do you think?

I'd also appreciate @zmbq opininon on this.

Thanks

@yosefm
Copy link
Member Author

yosefm commented Sep 8, 2019

Yes, I think keeping the liboptv tests and the docs for how to run them is important. When I do dev. work on that level, I should have a tool to directly test the code without all the Python layers. Besides, keeping this library general enough so that someone can use it from other languages is good software engineering. It "keeps you honest" and prevents the UI and the core logic from mixing.

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

2 participants