CI = continuous integration :) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Chief Architect Instrument Software and Science Data Systems Section (398) NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 168-519, Mailstop: 168-527 Email: [email protected] WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Director, Information Retrieval and Data Science Group (IRDS) Adjunct Associate Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA WWW: http://irds.usc.edu/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
On 7/11/16, 4:50 PM, "Matt Post" <[email protected]> wrote: >This sounds fine to me. What does CI stand for? > >Another thing we should do, which might be complementary to this, is just be >more formal about our process. I had been using this method for a while: > > http://nvie.com/posts/a-successful-git-branching-model/ > >Sort of informally, but that could be a good approach (I think someone >suggested it a while ago). In short: > >- "master" is always stable and records official releases >- development takes place on "develop" >- if you need to make an important fix, you branch off master, fix it, then >merge that into both "master" (as a point release) and "develop" > >I was using "release" for releases and "master" for develop, but we could >adopt anything. > >Kellen, how does this fit with CI? It seems like we could set it up to do >testing on "master" and "develop" branches --- the first as a sanity check, >and the second as a test for when we could merge into master? > >matt > > >> On Jul 11, 2016, at 8:17 AM, kellen sunderland <[email protected]> >> wrote: >> >> We've made a lot of progress on moving the project over to Apache + Maven. >> I was wondering if now would be a good time to consider re-thinking how we >> merge changes into master. The main goal would be to make sure we have a >> stable master branch that everyone can pull from. >> >> What I'd suggest is that we only merge into master once CI has completed >> testing. This way we can codify style rules, best practices, and make sure >> builds succeed and tests pass. We can develop new features create PRs as >> normal, and then get quick feedback if those PRs are mergable. I'd also >> suggest we dis-allow manual pushing to the master branch. >> >> I'm not sure how much effort this would be with the existing CI server, but >> I could investigate this if someone could grant me admin permissions. If >> it's a Jenkins server I'm sure it's possible. >> >> Another option is to use Travis CI. I have taken a quick look at Travis CI >> and it seems like a quite polished solution. It's free to use for open >> source projects. It supports automatically building + testing PRs. The >> interface is really clean. It has email notifications and group >> administration support. It's got support for multiple (programming) >> languages so we could in theory build kenlm as a build step and run those >> tests. >> >> Here's some more info on what the workflow with Travis-CI and PRs would be >> https://docs.travis-ci.com/user/pull-requests >> >> What do you guys think? Is there a strong preference for using Jenkins >> from the Apache community? Would everyone be ok with avoiding direct >> pushes to master? >> >> -Kellen >
