integrate with travis ci #7
Conversation
|
I'm an interested bystander (I forked pyeuclid to geometryFramed.) I haven't read Travis docs. My questions may not be appropriate. Is the makefile depending on tools from python2.4 and 2.5 in certain hard locations compatible with travis? How often will travis build? Is it integrated with Github enough to build only when there is a new commit? How does that help developers (working on their own branch) do continuous integration? Does a developer sic Travis on their own branch on Github? |
|
@bootchk Check out my master branch as an example. In my master branch I have also added http://coveralls.io integration so I can see what percentage of the code is covered by tests. I would be happy to make a pull request for that as well once this request is merged in. This pull request depends on my other request (#6) which drops support for python 2.4/2.5. The makefile depends on the To answer your last question, it helps developers on their own branch because you can do exactly what I did and enable your own repo on travis-ci so it can run tests for your commits. |
|
Thanks, that is very informative. But shouldn't a developer make (which runs the tests) before doing a commit. So travis provides assurances to other developers that a developer's commit will pass tests on all versions of Python. That seems worthy. |
|
You're right of course. Ideally a developer should make on all supported versions of python before commiting, but I kind of like letting travis take care of that for me. Then if I end up with too many commits in my branch, sometimes I'll rebase to clean it up a bit. |
|
(This might not be the appropriate place for this question...) Why did you fork, or why are you bothering to submit pull requests? In other words, I'm wondering about the social aspects and the problem with having too many forks. How are others to choose between your repository and this one? I would guess that by submitting pull requests here, you are trying to keep the repositories equal. If your pull requests here are not being honored (apparently), then your fork becomes divergent? Then are you committing yourself to capture any fixes made here and in the ancestor google project (assuming some people make fixes here and there) so that your divergent fork becomes the defacto best one, since it is maintained? Note I'm not suggesting you do anything particular or that you have done anything wrong. I'm just wondering how you see the situation. (As someone who has also forked and diverged this project. As I recall, I informally suggested changes to the project (frame safety and separating vectors from points, but it was not well received. But I needed it, so I forked. I wouldn't claim my fork is better, just different.) |
|
Whenever I contribute to an open source project I try and find the fork with the most current support and submit pull requests to that fork. Usually I'm just trying to help out with the project without committing to providing full-time support. I very much dislike using my own fork and merging in changes from the master fork. I just want to get my feature in there and then count on the project maintainer to continue support. Adding Travis integration is, in my mind, like oiling the gears of a machine, resulting in a better library for everyone to use. |
|
@ezag Thanks for the merges. Better late than never 😉 |
Along with my previous pull request to update the docs and Makefile (#6), this request integrates with travis-ci.org to provide continuous integration. It verifies that the pyeuclid docs and tests successfully build and that pyeuclid installs properly an pythons 2.6, .27, 3.2, 3.3 and pypy.