devicemap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Werner Keil <werner.k...@gmail.com>
Subject Re: GitHub and CI
Date Tue, 06 Jan 2015 22:30:31 GMT
Volkan,

Thanks a lot for the suggestion.
There is currently just one sub-project, BrowserMap with a Git repository
which is both synced into SVN and (at least Read Only) also to GitHub.
It does not seem feasable from Apache's policy to use GitHub as driving
repo with push access from that side. We had this discussion earlier and I
remember it sounded like that.

Applying a somewhat similar approach as Browsermap to other modules I would
not mind. Maybe we can simply do a vote on it.
The (bidirectional) sync with SVN may be tricky, at least for Browsermap it
ends up in a strange structure like /trunk/browsermap/trunk and a "parallel
SVN universe" with separate "tags" and "branches" folder, too.

Kind Regards,
Werner
Am 06.01.2015 22:50 schrieb "Volkan Yazıcı" <volkan.yazici@gmail.com>:

> Hello,
>
> 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
>    <https://coveralls.io/> 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
>    http://devicemap-vm.apache.org/data/latest/ used by DM clients, etc.)
> in
>    a VCS environment.
>
> Best.
>

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