Avoiding master failures with CI

[kellen sunderland <ke...@gmail.com>]

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

Re: Avoiding master failures with CI

[kellen sunderland <ke...@gmail.com>]

Friday is good for me.  Chat with you then.

If anyone else wants to hop on a hangout let me know.

On Wed, Jul 13, 2016 at 6:58 PM, Matt Post <po...@cs.jhu.edu> wrote:

> I misread the day, here, and thought you meant today. I can't do tomorrow
> afternoon, but that time on Friday works for me. We could also go into next
> week if that's better.
>
>
> > On Jul 13, 2016, at 9:41 AM, Matt Post <po...@cs.jhu.edu> wrote:
> >
> > That works for me. I've watched the video you linked so I have a feel
> for this, but I still think it'd be good to chat.
> >
> > matt
> >
> >
> >> On Jul 13, 2016, at 8:21 AM, kellen sunderland <
> kellen.sunderland@gmail.com> wrote:
> >>
> >> Would everyone be ok with tomorrow at 5PM UTC?
> >>
> >> -Kellen
> >>
> >> On Tue, Jul 12, 2016 at 8:35 PM, Matt Post <po...@cs.jhu.edu> wrote:
> >>
> >>> Hi Kellen,
> >>>
> >>> No worries, and you did provide a link. I think a Google Hangouts
> >>> walkthrough would be an efficient way to go about this. What day and
> time
> >>> work for you? I am mostly open this week.
> >>>
> >>> matt
> >>>
> >>>
> >>>> On Jul 11, 2016, at 6:50 PM, kellen sunderland <
> >>> kellen.sunderland@gmail.com> wrote:
> >>>>
> >>>> Sorry should have provided the link to this page:
> https://travis-ci.org/
> >>> .
> >>>> If you scroll down a bit on that page there's a Pull Request flow
> >>> section,
> >>>> it's the flow I'd be most in favour of.  There's also a decent (but
> >>> rushed)
> >>>> demo here: https://www.youtube.com/watch?v=Uft5KBimzyk .  We actually
> >>> don't
> >>>> need to do a lot of the work that he demos, i.e. no node or gulp
> >>>> configuration.  Our setup is close enough to default a default java
> >>> project
> >>>> that we just have to tell it to build java 8 and then it runs maven
> >>>> properly.
> >>>>
> >>>> Using a CI server would have some aspects that are similar to the
> >>> branching
> >>>> document you mention, and some benefits that are a bit orthogonal.
> Most
> >>> of
> >>>> these benefits have to do with unit testing, which isn't covered in
> the
> >>> doc.
> >>>>
> >>>> First the orthogonal benefits:  The main benefit we would get from
> using
> >>> CI
> >>>> is that we guarantee code in our repo is never broken.  That is to say
> >>>> tests always pass and it always builds correctly.  CI servers are
> really
> >>>> useful to prevent problems where one developer may have everything
> >>> working
> >>>> properly on his/her machine, but when they later realize it's not
> working
> >>>> on another devs machine.  A good example of this is the
> >>> class-based-lm-test
> >>>> we pushed recently.  It works fine for me locally but it would fail
> for
> >>>> anyone without kenlm.so.  There are many other examples (javadoc
> errors,
> >>>> code style, etc) but what will happen in these cases is we'll see a
> big
> >>>> obvious 'The build has problems' message in the PR page on Github.  If
> >>> the
> >>>> CI server runs of all of our code quality checks and finds that
> >>> everything
> >>>> is good we'll get a big 'This PR is ready to merge' message.
> >>>>
> >>>> Now to the part that overlaps a bit with branching.  There are various
> >>>> branching strategies that we could adopt for the project.  The master
> /
> >>> dev
> >>>> branch one is a possibility.  I'd suggest we try commit code strictly
> in
> >>>> PRs rather than pushing to git.  This would be the equivalent of
> feature
> >>>> branching from your link.  The reason I'd suggest that approach is
> that
> >>>> from what I've seen it'll be dead simple to get working with Github
> and
> >>>> Travis, and it gives us the same goal of having a stable master
> branch.
> >>>>
> >>>> If you'd like we can walk through setting this up together on a forked
> >>>> version of our Github repo.  We could do a quick example of how code
> >>> would
> >>>> be pushed and merged.  I should be available for a google hangout some
> >>> time
> >>>> this week if that works for you?
> >>>>
> >>>> -Kellen
> >>>>
> >>>>
> >>>> On Mon, Jul 11, 2016 at 10:51 PM, Mattmann, Chris A (3980) <
> >>>> chris.a.mattmann@jpl.nasa.gov> wrote:
> >>>>
> >>>>> 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: chris.a.mattmann@nasa.gov
> >>>>> 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" <po...@cs.jhu.edu> 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 <
> >>>>> kellen.sunderland@gmail.com> 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
> >>>>>>
> >>>>>
> >>>
> >>>
> >
>
>

Re: Avoiding master failures with CI

[Matt Post <po...@cs.jhu.edu>]

I misread the day, here, and thought you meant today. I can't do tomorrow afternoon, but that time on Friday works for me. We could also go into next week if that's better.


> On Jul 13, 2016, at 9:41 AM, Matt Post <po...@cs.jhu.edu> wrote:
> 
> That works for me. I've watched the video you linked so I have a feel for this, but I still think it'd be good to chat.
> 
> matt
> 
> 
>> On Jul 13, 2016, at 8:21 AM, kellen sunderland <ke...@gmail.com> wrote:
>> 
>> Would everyone be ok with tomorrow at 5PM UTC?
>> 
>> -Kellen
>> 
>> On Tue, Jul 12, 2016 at 8:35 PM, Matt Post <po...@cs.jhu.edu> wrote:
>> 
>>> Hi Kellen,
>>> 
>>> No worries, and you did provide a link. I think a Google Hangouts
>>> walkthrough would be an efficient way to go about this. What day and time
>>> work for you? I am mostly open this week.
>>> 
>>> matt
>>> 
>>> 
>>>> On Jul 11, 2016, at 6:50 PM, kellen sunderland <
>>> kellen.sunderland@gmail.com> wrote:
>>>> 
>>>> Sorry should have provided the link to this page: https://travis-ci.org/
>>> .
>>>> If you scroll down a bit on that page there's a Pull Request flow
>>> section,
>>>> it's the flow I'd be most in favour of.  There's also a decent (but
>>> rushed)
>>>> demo here: https://www.youtube.com/watch?v=Uft5KBimzyk .  We actually
>>> don't
>>>> need to do a lot of the work that he demos, i.e. no node or gulp
>>>> configuration.  Our setup is close enough to default a default java
>>> project
>>>> that we just have to tell it to build java 8 and then it runs maven
>>>> properly.
>>>> 
>>>> Using a CI server would have some aspects that are similar to the
>>> branching
>>>> document you mention, and some benefits that are a bit orthogonal.  Most
>>> of
>>>> these benefits have to do with unit testing, which isn't covered in the
>>> doc.
>>>> 
>>>> First the orthogonal benefits:  The main benefit we would get from using
>>> CI
>>>> is that we guarantee code in our repo is never broken.  That is to say
>>>> tests always pass and it always builds correctly.  CI servers are really
>>>> useful to prevent problems where one developer may have everything
>>> working
>>>> properly on his/her machine, but when they later realize it's not working
>>>> on another devs machine.  A good example of this is the
>>> class-based-lm-test
>>>> we pushed recently.  It works fine for me locally but it would fail for
>>>> anyone without kenlm.so.  There are many other examples (javadoc errors,
>>>> code style, etc) but what will happen in these cases is we'll see a big
>>>> obvious 'The build has problems' message in the PR page on Github.  If
>>> the
>>>> CI server runs of all of our code quality checks and finds that
>>> everything
>>>> is good we'll get a big 'This PR is ready to merge' message.
>>>> 
>>>> Now to the part that overlaps a bit with branching.  There are various
>>>> branching strategies that we could adopt for the project.  The master /
>>> dev
>>>> branch one is a possibility.  I'd suggest we try commit code strictly in
>>>> PRs rather than pushing to git.  This would be the equivalent of feature
>>>> branching from your link.  The reason I'd suggest that approach is that
>>>> from what I've seen it'll be dead simple to get working with Github and
>>>> Travis, and it gives us the same goal of having a stable master branch.
>>>> 
>>>> If you'd like we can walk through setting this up together on a forked
>>>> version of our Github repo.  We could do a quick example of how code
>>> would
>>>> be pushed and merged.  I should be available for a google hangout some
>>> time
>>>> this week if that works for you?
>>>> 
>>>> -Kellen
>>>> 
>>>> 
>>>> On Mon, Jul 11, 2016 at 10:51 PM, Mattmann, Chris A (3980) <
>>>> chris.a.mattmann@jpl.nasa.gov> wrote:
>>>> 
>>>>> 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: chris.a.mattmann@nasa.gov
>>>>> 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" <po...@cs.jhu.edu> 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 <
>>>>> kellen.sunderland@gmail.com> 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
>>>>>> 
>>>>> 
>>> 
>>> 
> 

Re: Avoiding master failures with CI

[Matt Post <po...@cs.jhu.edu>]

That works for me. I've watched the video you linked so I have a feel for this, but I still think it'd be good to chat.

matt


> On Jul 13, 2016, at 8:21 AM, kellen sunderland <ke...@gmail.com> wrote:
> 
> Would everyone be ok with tomorrow at 5PM UTC?
> 
> -Kellen
> 
> On Tue, Jul 12, 2016 at 8:35 PM, Matt Post <po...@cs.jhu.edu> wrote:
> 
>> Hi Kellen,
>> 
>> No worries, and you did provide a link. I think a Google Hangouts
>> walkthrough would be an efficient way to go about this. What day and time
>> work for you? I am mostly open this week.
>> 
>> matt
>> 
>> 
>>> On Jul 11, 2016, at 6:50 PM, kellen sunderland <
>> kellen.sunderland@gmail.com> wrote:
>>> 
>>> Sorry should have provided the link to this page: https://travis-ci.org/
>> .
>>> If you scroll down a bit on that page there's a Pull Request flow
>> section,
>>> it's the flow I'd be most in favour of.  There's also a decent (but
>> rushed)
>>> demo here: https://www.youtube.com/watch?v=Uft5KBimzyk .  We actually
>> don't
>>> need to do a lot of the work that he demos, i.e. no node or gulp
>>> configuration.  Our setup is close enough to default a default java
>> project
>>> that we just have to tell it to build java 8 and then it runs maven
>>> properly.
>>> 
>>> Using a CI server would have some aspects that are similar to the
>> branching
>>> document you mention, and some benefits that are a bit orthogonal.  Most
>> of
>>> these benefits have to do with unit testing, which isn't covered in the
>> doc.
>>> 
>>> First the orthogonal benefits:  The main benefit we would get from using
>> CI
>>> is that we guarantee code in our repo is never broken.  That is to say
>>> tests always pass and it always builds correctly.  CI servers are really
>>> useful to prevent problems where one developer may have everything
>> working
>>> properly on his/her machine, but when they later realize it's not working
>>> on another devs machine.  A good example of this is the
>> class-based-lm-test
>>> we pushed recently.  It works fine for me locally but it would fail for
>>> anyone without kenlm.so.  There are many other examples (javadoc errors,
>>> code style, etc) but what will happen in these cases is we'll see a big
>>> obvious 'The build has problems' message in the PR page on Github.  If
>> the
>>> CI server runs of all of our code quality checks and finds that
>> everything
>>> is good we'll get a big 'This PR is ready to merge' message.
>>> 
>>> Now to the part that overlaps a bit with branching.  There are various
>>> branching strategies that we could adopt for the project.  The master /
>> dev
>>> branch one is a possibility.  I'd suggest we try commit code strictly in
>>> PRs rather than pushing to git.  This would be the equivalent of feature
>>> branching from your link.  The reason I'd suggest that approach is that
>>> from what I've seen it'll be dead simple to get working with Github and
>>> Travis, and it gives us the same goal of having a stable master branch.
>>> 
>>> If you'd like we can walk through setting this up together on a forked
>>> version of our Github repo.  We could do a quick example of how code
>> would
>>> be pushed and merged.  I should be available for a google hangout some
>> time
>>> this week if that works for you?
>>> 
>>> -Kellen
>>> 
>>> 
>>> On Mon, Jul 11, 2016 at 10:51 PM, Mattmann, Chris A (3980) <
>>> chris.a.mattmann@jpl.nasa.gov> wrote:
>>> 
>>>> 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: chris.a.mattmann@nasa.gov
>>>> 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" <po...@cs.jhu.edu> 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 <
>>>> kellen.sunderland@gmail.com> 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
>>>>> 
>>>> 
>> 
>> 

Re: Avoiding master failures with CI

[kellen sunderland <ke...@gmail.com>]

Would everyone be ok with tomorrow at 5PM UTC?

-Kellen

On Tue, Jul 12, 2016 at 8:35 PM, Matt Post <po...@cs.jhu.edu> wrote:

> Hi Kellen,
>
> No worries, and you did provide a link. I think a Google Hangouts
> walkthrough would be an efficient way to go about this. What day and time
> work for you? I am mostly open this week.
>
> matt
>
>
> > On Jul 11, 2016, at 6:50 PM, kellen sunderland <
> kellen.sunderland@gmail.com> wrote:
> >
> > Sorry should have provided the link to this page: https://travis-ci.org/
> .
> > If you scroll down a bit on that page there's a Pull Request flow
> section,
> > it's the flow I'd be most in favour of.  There's also a decent (but
> rushed)
> > demo here: https://www.youtube.com/watch?v=Uft5KBimzyk .  We actually
> don't
> > need to do a lot of the work that he demos, i.e. no node or gulp
> > configuration.  Our setup is close enough to default a default java
> project
> > that we just have to tell it to build java 8 and then it runs maven
> > properly.
> >
> > Using a CI server would have some aspects that are similar to the
> branching
> > document you mention, and some benefits that are a bit orthogonal.  Most
> of
> > these benefits have to do with unit testing, which isn't covered in the
> doc.
> >
> > First the orthogonal benefits:  The main benefit we would get from using
> CI
> > is that we guarantee code in our repo is never broken.  That is to say
> > tests always pass and it always builds correctly.  CI servers are really
> > useful to prevent problems where one developer may have everything
> working
> > properly on his/her machine, but when they later realize it's not working
> > on another devs machine.  A good example of this is the
> class-based-lm-test
> > we pushed recently.  It works fine for me locally but it would fail for
> > anyone without kenlm.so.  There are many other examples (javadoc errors,
> > code style, etc) but what will happen in these cases is we'll see a big
> > obvious 'The build has problems' message in the PR page on Github.  If
> the
> > CI server runs of all of our code quality checks and finds that
> everything
> > is good we'll get a big 'This PR is ready to merge' message.
> >
> > Now to the part that overlaps a bit with branching.  There are various
> > branching strategies that we could adopt for the project.  The master /
> dev
> > branch one is a possibility.  I'd suggest we try commit code strictly in
> > PRs rather than pushing to git.  This would be the equivalent of feature
> > branching from your link.  The reason I'd suggest that approach is that
> > from what I've seen it'll be dead simple to get working with Github and
> > Travis, and it gives us the same goal of having a stable master branch.
> >
> > If you'd like we can walk through setting this up together on a forked
> > version of our Github repo.  We could do a quick example of how code
> would
> > be pushed and merged.  I should be available for a google hangout some
> time
> > this week if that works for you?
> >
> > -Kellen
> >
> >
> > On Mon, Jul 11, 2016 at 10:51 PM, Mattmann, Chris A (3980) <
> > chris.a.mattmann@jpl.nasa.gov> wrote:
> >
> >> 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: chris.a.mattmann@nasa.gov
> >> 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" <po...@cs.jhu.edu> 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 <
> >> kellen.sunderland@gmail.com> 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
> >>>
> >>
>
>

Re: Avoiding master failures with CI

[Matt Post <po...@cs.jhu.edu>]

Hi Kellen,

No worries, and you did provide a link. I think a Google Hangouts walkthrough would be an efficient way to go about this. What day and time work for you? I am mostly open this week.

matt


> On Jul 11, 2016, at 6:50 PM, kellen sunderland <ke...@gmail.com> wrote:
> 
> Sorry should have provided the link to this page: https://travis-ci.org/ .
> If you scroll down a bit on that page there's a Pull Request flow section,
> it's the flow I'd be most in favour of.  There's also a decent (but rushed)
> demo here: https://www.youtube.com/watch?v=Uft5KBimzyk .  We actually don't
> need to do a lot of the work that he demos, i.e. no node or gulp
> configuration.  Our setup is close enough to default a default java project
> that we just have to tell it to build java 8 and then it runs maven
> properly.
> 
> Using a CI server would have some aspects that are similar to the branching
> document you mention, and some benefits that are a bit orthogonal.  Most of
> these benefits have to do with unit testing, which isn't covered in the doc.
> 
> First the orthogonal benefits:  The main benefit we would get from using CI
> is that we guarantee code in our repo is never broken.  That is to say
> tests always pass and it always builds correctly.  CI servers are really
> useful to prevent problems where one developer may have everything working
> properly on his/her machine, but when they later realize it's not working
> on another devs machine.  A good example of this is the class-based-lm-test
> we pushed recently.  It works fine for me locally but it would fail for
> anyone without kenlm.so.  There are many other examples (javadoc errors,
> code style, etc) but what will happen in these cases is we'll see a big
> obvious 'The build has problems' message in the PR page on Github.  If the
> CI server runs of all of our code quality checks and finds that everything
> is good we'll get a big 'This PR is ready to merge' message.
> 
> Now to the part that overlaps a bit with branching.  There are various
> branching strategies that we could adopt for the project.  The master / dev
> branch one is a possibility.  I'd suggest we try commit code strictly in
> PRs rather than pushing to git.  This would be the equivalent of feature
> branching from your link.  The reason I'd suggest that approach is that
> from what I've seen it'll be dead simple to get working with Github and
> Travis, and it gives us the same goal of having a stable master branch.
> 
> If you'd like we can walk through setting this up together on a forked
> version of our Github repo.  We could do a quick example of how code would
> be pushed and merged.  I should be available for a google hangout some time
> this week if that works for you?
> 
> -Kellen
> 
> 
> On Mon, Jul 11, 2016 at 10:51 PM, Mattmann, Chris A (3980) <
> chris.a.mattmann@jpl.nasa.gov> wrote:
> 
>> 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: chris.a.mattmann@nasa.gov
>> 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" <po...@cs.jhu.edu> 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 <
>> kellen.sunderland@gmail.com> 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
>>> 
>> 

Re: Avoiding master failures with CI

[Matt Post <po...@cs.jhu.edu>]

Thanks, done.

https://issues.apache.org/jira/browse/INFRA-12301?jql=project%20%3D%20INFRA


> On Jul 15, 2016, at 6:31 PM, Mattmann, Chris A (3980) <ch...@jpl.nasa.gov> wrote:
> 
> Hey Matt,
> 
> Apache infra supports Travis CI - just file a ticket and they will
> set it up :)
> 
> Cheers,
> Chris
> 
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 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: chris.a.mattmann@nasa.gov
> 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/15/16, 2:05 PM, "Matt Post" <po...@cs.jhu.edu> wrote:
> 
>> Question for Chris and/or Lewis:
>> 
>> So, Kellen and I took a look at this today, and it looks like a good solution. The problem is that it integrates with projects hosted on Github that you have write access to. In order to make use of this, we'd need to rearrange the setup we have.
>> 
>> Currently, we push to a repo at git.apache.org, and that is then pushed down to github.com/apache/incubator-joshua. This lets us use the Github repo for receiving things like pull requests and so on, but we do not have write access to it, so merges and so on have to be handled manually.
>> 
>> To use Travis-ci, we'd need to re-enginneer this. Apache would need to give us write access to github.com/apache/incubator-joshua, or we'd need to use another official host for Joshua. We'd then use git.apache.org as the mirror, instead of the other way around.
>> 
>> Is there any way that this could be done? I understand Apache's arguments about keeping discussions at home, since github may not last forever. However, it seems like we could do this if we use git.apache.org as the backup mirror, and continue to use JIRA for discussions and so on. In general, Github has a lot of tools that could help with development. It would be nice if we could make use of them while still checking off Apache's logging requirements.
>> 
>> matt
>> 
>> 
>> 
>>> On Jul 11, 2016, at 6:50 PM, kellen sunderland <ke...@gmail.com> wrote:
>>> 
>>> Sorry should have provided the link to this page: https://travis-ci.org/ .
>>> If you scroll down a bit on that page there's a Pull Request flow section,
>>> it's the flow I'd be most in favour of.  There's also a decent (but rushed)
>>> demo here: https://www.youtube.com/watch?v=Uft5KBimzyk .  We actually don't
>>> need to do a lot of the work that he demos, i.e. no node or gulp
>>> configuration.  Our setup is close enough to default a default java project
>>> that we just have to tell it to build java 8 and then it runs maven
>>> properly.
>>> 
>>> Using a CI server would have some aspects that are similar to the branching
>>> document you mention, and some benefits that are a bit orthogonal.  Most of
>>> these benefits have to do with unit testing, which isn't covered in the doc.
>>> 
>>> First the orthogonal benefits:  The main benefit we would get from using CI
>>> is that we guarantee code in our repo is never broken.  That is to say
>>> tests always pass and it always builds correctly.  CI servers are really
>>> useful to prevent problems where one developer may have everything working
>>> properly on his/her machine, but when they later realize it's not working
>>> on another devs machine.  A good example of this is the class-based-lm-test
>>> we pushed recently.  It works fine for me locally but it would fail for
>>> anyone without kenlm.so.  There are many other examples (javadoc errors,
>>> code style, etc) but what will happen in these cases is we'll see a big
>>> obvious 'The build has problems' message in the PR page on Github.  If the
>>> CI server runs of all of our code quality checks and finds that everything
>>> is good we'll get a big 'This PR is ready to merge' message.
>>> 
>>> Now to the part that overlaps a bit with branching.  There are various
>>> branching strategies that we could adopt for the project.  The master / dev
>>> branch one is a possibility.  I'd suggest we try commit code strictly in
>>> PRs rather than pushing to git.  This would be the equivalent of feature
>>> branching from your link.  The reason I'd suggest that approach is that
>>> from what I've seen it'll be dead simple to get working with Github and
>>> Travis, and it gives us the same goal of having a stable master branch.
>>> 
>>> If you'd like we can walk through setting this up together on a forked
>>> version of our Github repo.  We could do a quick example of how code would
>>> be pushed and merged.  I should be available for a google hangout some time
>>> this week if that works for you?
>>> 
>>> -Kellen
>>> 
>>> 
>>> On Mon, Jul 11, 2016 at 10:51 PM, Mattmann, Chris A (3980) <
>>> chris.a.mattmann@jpl.nasa.gov> wrote:
>>> 
>>>> 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: chris.a.mattmann@nasa.gov
>>>> 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" <po...@cs.jhu.edu> 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 <
>>>> kellen.sunderland@gmail.com> 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
>>>>> 
>>>> 
>> 

Re: Avoiding master failures with CI

[Tom Barber <to...@analytical-labs.com>]

Don't ask about github pushing.... its like the antichrist! ;)

--------------

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart
<http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/>
goal, but you can always help by sponsoring the project
<http://www.meteorite.bi/products/saiku/sponsorship>)

On 15 July 2016 at 23:31, Mattmann, Chris A (3980) <
chris.a.mattmann@jpl.nasa.gov> wrote:

> Hey Matt,
>
> Apache infra supports Travis CI - just file a ticket and they will
> set it up :)
>
> Cheers,
> Chris
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 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: chris.a.mattmann@nasa.gov
> 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/15/16, 2:05 PM, "Matt Post" <po...@cs.jhu.edu> wrote:
>
> >Question for Chris and/or Lewis:
> >
> >So, Kellen and I took a look at this today, and it looks like a good
> solution. The problem is that it integrates with projects hosted on Github
> that you have write access to. In order to make use of this, we'd need to
> rearrange the setup we have.
> >
> >Currently, we push to a repo at git.apache.org, and that is then pushed
> down to github.com/apache/incubator-joshua. This lets us use the Github
> repo for receiving things like pull requests and so on, but we do not have
> write access to it, so merges and so on have to be handled manually.
> >
> >To use Travis-ci, we'd need to re-enginneer this. Apache would need to
> give us write access to github.com/apache/incubator-joshua, or we'd need
> to use another official host for Joshua. We'd then use git.apache.org as
> the mirror, instead of the other way around.
> >
> >Is there any way that this could be done? I understand Apache's arguments
> about keeping discussions at home, since github may not last forever.
> However, it seems like we could do this if we use git.apache.org as the
> backup mirror, and continue to use JIRA for discussions and so on. In
> general, Github has a lot of tools that could help with development. It
> would be nice if we could make use of them while still checking off
> Apache's logging requirements.
> >
> >matt
> >
> >
> >
> >> On Jul 11, 2016, at 6:50 PM, kellen sunderland <
> kellen.sunderland@gmail.com> wrote:
> >>
> >> Sorry should have provided the link to this page:
> https://travis-ci.org/ .
> >> If you scroll down a bit on that page there's a Pull Request flow
> section,
> >> it's the flow I'd be most in favour of.  There's also a decent (but
> rushed)
> >> demo here: https://www.youtube.com/watch?v=Uft5KBimzyk .  We actually
> don't
> >> need to do a lot of the work that he demos, i.e. no node or gulp
> >> configuration.  Our setup is close enough to default a default java
> project
> >> that we just have to tell it to build java 8 and then it runs maven
> >> properly.
> >>
> >> Using a CI server would have some aspects that are similar to the
> branching
> >> document you mention, and some benefits that are a bit orthogonal.
> Most of
> >> these benefits have to do with unit testing, which isn't covered in the
> doc.
> >>
> >> First the orthogonal benefits:  The main benefit we would get from
> using CI
> >> is that we guarantee code in our repo is never broken.  That is to say
> >> tests always pass and it always builds correctly.  CI servers are really
> >> useful to prevent problems where one developer may have everything
> working
> >> properly on his/her machine, but when they later realize it's not
> working
> >> on another devs machine.  A good example of this is the
> class-based-lm-test
> >> we pushed recently.  It works fine for me locally but it would fail for
> >> anyone without kenlm.so.  There are many other examples (javadoc errors,
> >> code style, etc) but what will happen in these cases is we'll see a big
> >> obvious 'The build has problems' message in the PR page on Github.  If
> the
> >> CI server runs of all of our code quality checks and finds that
> everything
> >> is good we'll get a big 'This PR is ready to merge' message.
> >>
> >> Now to the part that overlaps a bit with branching.  There are various
> >> branching strategies that we could adopt for the project.  The master /
> dev
> >> branch one is a possibility.  I'd suggest we try commit code strictly in
> >> PRs rather than pushing to git.  This would be the equivalent of feature
> >> branching from your link.  The reason I'd suggest that approach is that
> >> from what I've seen it'll be dead simple to get working with Github and
> >> Travis, and it gives us the same goal of having a stable master branch.
> >>
> >> If you'd like we can walk through setting this up together on a forked
> >> version of our Github repo.  We could do a quick example of how code
> would
> >> be pushed and merged.  I should be available for a google hangout some
> time
> >> this week if that works for you?
> >>
> >> -Kellen
> >>
> >>
> >> On Mon, Jul 11, 2016 at 10:51 PM, Mattmann, Chris A (3980) <
> >> chris.a.mattmann@jpl.nasa.gov> wrote:
> >>
> >>> 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: chris.a.mattmann@nasa.gov
> >>> 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" <po...@cs.jhu.edu> 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 <
> >>> kellen.sunderland@gmail.com> 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
> >>>>
> >>>
> >
>

Re: Avoiding master failures with CI

["Mattmann, Chris A (3980)" <ch...@jpl.nasa.gov>]

Hey Matt,

Apache infra supports Travis CI - just file a ticket and they will
set it up :)

Cheers,
Chris

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
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: chris.a.mattmann@nasa.gov
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/15/16, 2:05 PM, "Matt Post" <po...@cs.jhu.edu> wrote:

>Question for Chris and/or Lewis:
>
>So, Kellen and I took a look at this today, and it looks like a good solution. The problem is that it integrates with projects hosted on Github that you have write access to. In order to make use of this, we'd need to rearrange the setup we have.
>
>Currently, we push to a repo at git.apache.org, and that is then pushed down to github.com/apache/incubator-joshua. This lets us use the Github repo for receiving things like pull requests and so on, but we do not have write access to it, so merges and so on have to be handled manually.
>
>To use Travis-ci, we'd need to re-enginneer this. Apache would need to give us write access to github.com/apache/incubator-joshua, or we'd need to use another official host for Joshua. We'd then use git.apache.org as the mirror, instead of the other way around.
>
>Is there any way that this could be done? I understand Apache's arguments about keeping discussions at home, since github may not last forever. However, it seems like we could do this if we use git.apache.org as the backup mirror, and continue to use JIRA for discussions and so on. In general, Github has a lot of tools that could help with development. It would be nice if we could make use of them while still checking off Apache's logging requirements.
>
>matt
>
>
>
>> On Jul 11, 2016, at 6:50 PM, kellen sunderland <ke...@gmail.com> wrote:
>> 
>> Sorry should have provided the link to this page: https://travis-ci.org/ .
>> If you scroll down a bit on that page there's a Pull Request flow section,
>> it's the flow I'd be most in favour of.  There's also a decent (but rushed)
>> demo here: https://www.youtube.com/watch?v=Uft5KBimzyk .  We actually don't
>> need to do a lot of the work that he demos, i.e. no node or gulp
>> configuration.  Our setup is close enough to default a default java project
>> that we just have to tell it to build java 8 and then it runs maven
>> properly.
>> 
>> Using a CI server would have some aspects that are similar to the branching
>> document you mention, and some benefits that are a bit orthogonal.  Most of
>> these benefits have to do with unit testing, which isn't covered in the doc.
>> 
>> First the orthogonal benefits:  The main benefit we would get from using CI
>> is that we guarantee code in our repo is never broken.  That is to say
>> tests always pass and it always builds correctly.  CI servers are really
>> useful to prevent problems where one developer may have everything working
>> properly on his/her machine, but when they later realize it's not working
>> on another devs machine.  A good example of this is the class-based-lm-test
>> we pushed recently.  It works fine for me locally but it would fail for
>> anyone without kenlm.so.  There are many other examples (javadoc errors,
>> code style, etc) but what will happen in these cases is we'll see a big
>> obvious 'The build has problems' message in the PR page on Github.  If the
>> CI server runs of all of our code quality checks and finds that everything
>> is good we'll get a big 'This PR is ready to merge' message.
>> 
>> Now to the part that overlaps a bit with branching.  There are various
>> branching strategies that we could adopt for the project.  The master / dev
>> branch one is a possibility.  I'd suggest we try commit code strictly in
>> PRs rather than pushing to git.  This would be the equivalent of feature
>> branching from your link.  The reason I'd suggest that approach is that
>> from what I've seen it'll be dead simple to get working with Github and
>> Travis, and it gives us the same goal of having a stable master branch.
>> 
>> If you'd like we can walk through setting this up together on a forked
>> version of our Github repo.  We could do a quick example of how code would
>> be pushed and merged.  I should be available for a google hangout some time
>> this week if that works for you?
>> 
>> -Kellen
>> 
>> 
>> On Mon, Jul 11, 2016 at 10:51 PM, Mattmann, Chris A (3980) <
>> chris.a.mattmann@jpl.nasa.gov> wrote:
>> 
>>> 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: chris.a.mattmann@nasa.gov
>>> 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" <po...@cs.jhu.edu> 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 <
>>> kellen.sunderland@gmail.com> 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
>>>> 
>>> 
>

Re: Avoiding master failures with CI

[Matt Post <po...@cs.jhu.edu>]

Question for Chris and/or Lewis:

So, Kellen and I took a look at this today, and it looks like a good solution. The problem is that it integrates with projects hosted on Github that you have write access to. In order to make use of this, we'd need to rearrange the setup we have.

Currently, we push to a repo at git.apache.org, and that is then pushed down to github.com/apache/incubator-joshua. This lets us use the Github repo for receiving things like pull requests and so on, but we do not have write access to it, so merges and so on have to be handled manually.

To use Travis-ci, we'd need to re-enginneer this. Apache would need to give us write access to github.com/apache/incubator-joshua, or we'd need to use another official host for Joshua. We'd then use git.apache.org as the mirror, instead of the other way around.

Is there any way that this could be done? I understand Apache's arguments about keeping discussions at home, since github may not last forever. However, it seems like we could do this if we use git.apache.org as the backup mirror, and continue to use JIRA for discussions and so on. In general, Github has a lot of tools that could help with development. It would be nice if we could make use of them while still checking off Apache's logging requirements.

matt



> On Jul 11, 2016, at 6:50 PM, kellen sunderland <ke...@gmail.com> wrote:
> 
> Sorry should have provided the link to this page: https://travis-ci.org/ .
> If you scroll down a bit on that page there's a Pull Request flow section,
> it's the flow I'd be most in favour of.  There's also a decent (but rushed)
> demo here: https://www.youtube.com/watch?v=Uft5KBimzyk .  We actually don't
> need to do a lot of the work that he demos, i.e. no node or gulp
> configuration.  Our setup is close enough to default a default java project
> that we just have to tell it to build java 8 and then it runs maven
> properly.
> 
> Using a CI server would have some aspects that are similar to the branching
> document you mention, and some benefits that are a bit orthogonal.  Most of
> these benefits have to do with unit testing, which isn't covered in the doc.
> 
> First the orthogonal benefits:  The main benefit we would get from using CI
> is that we guarantee code in our repo is never broken.  That is to say
> tests always pass and it always builds correctly.  CI servers are really
> useful to prevent problems where one developer may have everything working
> properly on his/her machine, but when they later realize it's not working
> on another devs machine.  A good example of this is the class-based-lm-test
> we pushed recently.  It works fine for me locally but it would fail for
> anyone without kenlm.so.  There are many other examples (javadoc errors,
> code style, etc) but what will happen in these cases is we'll see a big
> obvious 'The build has problems' message in the PR page on Github.  If the
> CI server runs of all of our code quality checks and finds that everything
> is good we'll get a big 'This PR is ready to merge' message.
> 
> Now to the part that overlaps a bit with branching.  There are various
> branching strategies that we could adopt for the project.  The master / dev
> branch one is a possibility.  I'd suggest we try commit code strictly in
> PRs rather than pushing to git.  This would be the equivalent of feature
> branching from your link.  The reason I'd suggest that approach is that
> from what I've seen it'll be dead simple to get working with Github and
> Travis, and it gives us the same goal of having a stable master branch.
> 
> If you'd like we can walk through setting this up together on a forked
> version of our Github repo.  We could do a quick example of how code would
> be pushed and merged.  I should be available for a google hangout some time
> this week if that works for you?
> 
> -Kellen
> 
> 
> On Mon, Jul 11, 2016 at 10:51 PM, Mattmann, Chris A (3980) <
> chris.a.mattmann@jpl.nasa.gov> wrote:
> 
>> 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: chris.a.mattmann@nasa.gov
>> 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" <po...@cs.jhu.edu> 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 <
>> kellen.sunderland@gmail.com> 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
>>> 
>> 

Re: Avoiding master failures with CI

[kellen sunderland <ke...@gmail.com>]

Sorry should have provided the link to this page: https://travis-ci.org/ .
If you scroll down a bit on that page there's a Pull Request flow section,
it's the flow I'd be most in favour of.  There's also a decent (but rushed)
demo here: https://www.youtube.com/watch?v=Uft5KBimzyk .  We actually don't
need to do a lot of the work that he demos, i.e. no node or gulp
configuration.  Our setup is close enough to default a default java project
that we just have to tell it to build java 8 and then it runs maven
properly.

Using a CI server would have some aspects that are similar to the branching
document you mention, and some benefits that are a bit orthogonal.  Most of
these benefits have to do with unit testing, which isn't covered in the doc.

First the orthogonal benefits:  The main benefit we would get from using CI
is that we guarantee code in our repo is never broken.  That is to say
tests always pass and it always builds correctly.  CI servers are really
useful to prevent problems where one developer may have everything working
properly on his/her machine, but when they later realize it's not working
on another devs machine.  A good example of this is the class-based-lm-test
we pushed recently.  It works fine for me locally but it would fail for
anyone without kenlm.so.  There are many other examples (javadoc errors,
code style, etc) but what will happen in these cases is we'll see a big
obvious 'The build has problems' message in the PR page on Github.  If the
CI server runs of all of our code quality checks and finds that everything
is good we'll get a big 'This PR is ready to merge' message.

Now to the part that overlaps a bit with branching.  There are various
branching strategies that we could adopt for the project.  The master / dev
branch one is a possibility.  I'd suggest we try commit code strictly in
PRs rather than pushing to git.  This would be the equivalent of feature
branching from your link.  The reason I'd suggest that approach is that
from what I've seen it'll be dead simple to get working with Github and
Travis, and it gives us the same goal of having a stable master branch.

If you'd like we can walk through setting this up together on a forked
version of our Github repo.  We could do a quick example of how code would
be pushed and merged.  I should be available for a google hangout some time
this week if that works for you?

-Kellen


On Mon, Jul 11, 2016 at 10:51 PM, Mattmann, Chris A (3980) <
chris.a.mattmann@jpl.nasa.gov> wrote:

> 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: chris.a.mattmann@nasa.gov
> 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" <po...@cs.jhu.edu> 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 <
> kellen.sunderland@gmail.com> 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
> >
>

Re: Avoiding master failures with CI

["Mattmann, Chris A (3980)" <ch...@jpl.nasa.gov>]

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: chris.a.mattmann@nasa.gov
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" <po...@cs.jhu.edu> 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 <ke...@gmail.com> 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
>

Re: Avoiding master failures with CI

[Matt Post <po...@cs.jhu.edu>]

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 <ke...@gmail.com> 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

Re: Avoiding master failures with CI

[Thamme Gowda <tg...@gmail.com>]

+1

++1 for automation and stability.

--
*Thamme Gowda *


2016-07-11 6:00 GMT-07:00 Mattmann, Chris A (3980) <
chris.a.mattmann@jpl.nasa.gov>:

> +1 let’s start using Travis - CI IMO..
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 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: chris.a.mattmann@nasa.gov
> 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, 8:17 AM, "kellen sunderland" <ke...@gmail.com>
> 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
>

Re: Avoiding master failures with CI

["Mattmann, Chris A (3980)" <ch...@jpl.nasa.gov>]

+1 let’s start using Travis - CI IMO..

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
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: chris.a.mattmann@nasa.gov
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, 8:17 AM, "kellen sunderland" <ke...@gmail.com> 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