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
