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

Reply via email to