devicemap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Volkan Yazıcı <>
Subject GitHub and CI
Date Tue, 06 Jan 2015 21:50:24 GMT

I had brought this issue up in the past, but I believe is neglected in the
middle of the storm. I (deadly) request from the board to migrate the
project from Subversion to GitHub. Below I explained my personal take on
the issue:

*Using Git:*

   - Developers will not need an internet connection to work on the code
   base. (My patch that increases Java client's performance by >2x was written
   on the train.)
   - Developers will be able to keep separate branches for each feature
   that they are currently working on.
   - Instead of a single huge monolithic commit, a feature will be pushed
   in small, semantically meaningful commits via branch merges.
   - While working on multiple features sitting on top of each other (e.g.,
   [feature2:] writing a console client, [feature1:] using a JSON parser
   previously fixed), developer will not need to wait for the owner of the
   project to apply changes to the master.

*Using GitHub:*

   - GitHub migration will attract and encourage a lot more people from
   F/OSS community to contribute. (You can just login and click "edit" on a
   file. Then project gets cloned for you and your changes are sent back as a
   pull request to the origin.)
   - We could have easily implemented a CI via Travis+GitHub integration in
   a matter of minutes. (We have been talking about it for almost 2 weeks.)
   - Similarly, we could have integrated code coverage
   <> in a couple of hours.
   - GitHub provides a really developer-friendly and efficient
   push-review-modify cycle that is accessible through a web interface. (Right
   now, we need to attach patches to JIRA issues and wait for somebody to
   download them, apply them, run them, and comment on the patch.)
   - Using GitHub pages, we will be able to keep and track the static files
   (JBake/Jekyll powered content, files under used by DM clients, etc.) in
   a VCS environment.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message