Re: Avoiding master failures with CI

[Mattmann, Chris A (3980)]

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.mattm...@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"  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  
>> 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
>

[jira] [Closed] (JOSHUA-71) OS X installation depends on coreutils to run thrax test

[Matt Post (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JOSHUA-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Post closed JOSHUA-71.
---
Resolution: Fixed

> OS X installation depends on coreutils to run thrax test
> 
>
> Key: JOSHUA-71
> URL: https://issues.apache.org/jira/browse/JOSHUA-71
> Project: Joshua
>  Issue Type: Bug
>Reporter: Luke Orland
> Fix For: 6.2
>
>
> the {{gstat}} command from coreutils is not installed in Darwin by default. 
> One must resolve that dependency via Homebrew, Macports, etc.
> The {{test/thrax/test.sh}} test will fail on an OS X system that does not 
> have coreutils installed. We should either change the test so that it does 
> not require coreutils in Darwin or make it clear in the (developer) 
> installation/setup instructions that coreutils are required for this test, 
> check for coreutils when running the thrax test, and output a helpful message 
> instructing the developer to go install coreutils if {{gstat}} is not found.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JOSHUA-71) OS X installation depends on coreutils to run thrax test

[Matt Post (JIRA)]

[ 
https://issues.apache.org/jira/browse/JOSHUA-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15371386#comment-15371386
 ] 

Matt Post commented on JOSHUA-71:
-

I don't think this issue applies any more.

> OS X installation depends on coreutils to run thrax test
> 
>
> Key: JOSHUA-71
> URL: https://issues.apache.org/jira/browse/JOSHUA-71
> Project: Joshua
>  Issue Type: Bug
>Reporter: Luke Orland
> Fix For: 6.2
>
>
> the {{gstat}} command from coreutils is not installed in Darwin by default. 
> One must resolve that dependency via Homebrew, Macports, etc.
> The {{test/thrax/test.sh}} test will fail on an OS X system that does not 
> have coreutils installed. We should either change the test so that it does 
> not require coreutils in Darwin or make it clear in the (developer) 
> installation/setup instructions that coreutils are required for this test, 
> check for coreutils when running the thrax test, and output a helpful message 
> instructing the developer to go install coreutils if {{gstat}} is not found.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (JOSHUA-251) Address Website Branding Issues

[Matt Post (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JOSHUA-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Post resolved JOSHUA-251.
--
   Resolution: Fixed
Fix Version/s: (was: 6.2)
   6.1

> Address Website Branding Issues
> ---
>
> Key: JOSHUA-251
> URL: https://issues.apache.org/jira/browse/JOSHUA-251
> Project: Joshua
>  Issue Type: Task
>Reporter: Lewis John McGibbney
>Priority: Critical
> Fix For: 6.1
>
>
> We have a number of Website branding issues which we need to address.
> http://www.apache.org/foundation/marks/pmcs.html#introduction
> Lets work through them here. Please create child issues if appropriate.
> Thanks



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JOSHUA-251) Address Website Branding Issues

[Matt Post (JIRA)]

[ 
https://issues.apache.org/jira/browse/JOSHUA-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15371380#comment-15371380
 ] 

Matt Post commented on JOSHUA-251:
--

I believe this is resolved with the following recent changes:

- Changed prominent mentions of "Joshua (Incubating)" to "Apache Joshua 
(Incubating)"
- Added the incubator disclaimer to the main page
- Added the incubator logo to the main page

> Address Website Branding Issues
> ---
>
> Key: JOSHUA-251
> URL: https://issues.apache.org/jira/browse/JOSHUA-251
> Project: Joshua
>  Issue Type: Task
>Reporter: Lewis John McGibbney
>Priority: Critical
> Fix For: 6.1
>
>
> We have a number of Website branding issues which we need to address.
> http://www.apache.org/foundation/marks/pmcs.html#introduction
> Lets work through them here. Please create child issues if appropriate.
> Thanks



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JOSHUA-4) Quasi-synchronous grammar

[Matt Post (JIRA)]

[ 
https://issues.apache.org/jira/browse/JOSHUA-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15371381#comment-15371381
 ] 

Matt Post commented on JOSHUA-4:


This is outside scope.

> Quasi-synchronous grammar
> -
>
> Key: JOSHUA-4
> URL: https://issues.apache.org/jira/browse/JOSHUA-4
> Project: Joshua
>  Issue Type: New Feature
>Reporter: Courtney Napoles
> Fix For: 6.2
>
>
> In the more long term, I think it would be worth looking into 
> quasi-synchronous grammar support in the decoder.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Avoiding master failures with CI

[Thamme Gowda]

+1

++1 for automation and stability.

--
*Thamme Gowda *


2016-07-11 6:00 GMT-07:00 Mattmann, Chris A (3980) <
chris.a.mattm...@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.mattm...@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" 
> 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)]

+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.mattm...@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"  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: [IMPORTANT] Roadmap for 6.1 Release

[kellen sunderland]

Thanks for organizing Lewis, sorry for the late replies.  Looking at the
frequency of our updates I'd suggest quarterly, or bi-annual releases.  If
we can keep the master branch stable (which should really be a goal of
ours) then hopefully it's not too much work to create the releases.I do
appreciate that there's probably some effort required to create release
notes + documentation.  Hopefully JIRA will be able to help us create some
of this documentation.

I'd agree that we should shoot for a 6.1 release fairly soon.  I'll review
the PRs that came from our side early after the Apache switch.  They should
probably have JIRA tickets tracking the changes with fix version assigned
as 6.1.

-Kellen



On Thu, Jun 23, 2016 at 11:01 PM, Tom Barber 
wrote:

> Hey Matt
>
> Over on  OODT our releases are few and far between, although that said,
> I've been trying to increase the frequency even if they are very minor. The
> main reason being, if someone commits some code, they don't want to wait 12
> months for it to hit a stable release! So you might say yearly major
> releases and patch releases at sporadic points inbetween to include patches
> people have submitted, this also keeps drive by committers interested
> because if they get some stuff into the codebase they then may commit more,
> rather than say "well I submitted a fix for issue x ages ago and its got
> notwhere".  Releases don't need to be set in stone, but I would try and
> keep them ticking over.
>
> Just my own 2 cents.
>
> Tom
>
> --
>
> 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
> )
>
> On 23 June 2016 at 21:56, Matt Post  wrote:
>
> > Hi Lewis,
> >
> > Sorry for taking some time to get back to you. I think the roadmap looks
> > great. One thing, though, is that the Amazon folks and I have discussed
> > making a number of backwards-incompatible changes in an effort to
> modernize
> > some pieces of the code. This would have to do with things like the
> config
> > file format, a totally new pipeline based on duct tape, and some other
> > ideas. We think those changes would be suitable for a 7.0 release (major
> > version number change signals backwards incompatibility).
> >
> > I think we've been doing some good work on improving Joshua, but at the
> > same time, I think the release cycle is still little too accelerated for
> > me. I would like to push back to semi- yearly or even yearly releases,
> with
> > bug fixes in between. However, I'm also curious how this might affect our
> > ability to move out of incubation. Do you have any thoughts on this?
> >
> > The major downsides to releases are documentation. It's just hard to find
> > the time to do.
> >
> > My own thoughts for what I'd like to do:
> >
> > - Maybe a 6.1 release (soon, to get it out of the way? or otherwise this
> > fall?), where we formalize the Apache move and maybe formalize the
> release
> > of a handful of language packs, without a lot of other changes
> >
> > - Write a linux.com article advertising this, hopefully attracting some
> > attention
> >
> > - Shoot for a 7.0 release with many of the changes we've discussed (some
> > offline). If we get a good showing at MT Marathon in Prague this year,
> that
> > could be a good time to get all of that in order.
> >
> > - Start getting to work on a version of Joshua that swaps out the core
> > decoder for a neural approach
> >
> > matt
> >
> >
> >
> >
> > > On Jun 23, 2016, at 4:13 PM, Tom Barber 
> wrote:
> > >
> > > I would volunteer some cycles for multi model support in the server and
> > an
> > > improved rest interface and basic UI for end user interaction if you
> > fancy
> > > it.
> > >
> > > --
> > >
> > > 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
> > > )
> > >
> > > On 23 June 2016 at 21:10, Lewis John Mcgibbney <
> > lewis.mcgibb...@gmail.com>
> > > wrote:
> > >
> > >> Hi Folks,
> > >> Anyone have any comments on this?
> > >> Seeing that the Maven multimodule project seems to be taking flight,
> it
> > >> would be nice to see where the roadmap is going?
> > >> Any comments would be great. Also, I'm kinda lost as to what is
> > happening
> > >> with Jira but it looks like it is not really being used for much.
> > >> Thanks
> > >>
> > >> On Mon, Jun 20, 2016 at 11:34 AM, Lewis John Mcgibbney <
> > >> 

[jira] [Commented] (JOSHUA-279) Cannot build Joshua master branch

[Kellen Sunderland (JIRA)]

[ 
https://issues.apache.org/jira/browse/JOSHUA-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15370387#comment-15370387
 ] 

Kellen Sunderland commented on JOSHUA-279:
--

Hey Lewis, sorry about these tests failing. We should not be breaking master 
like this, I'll try to ensure this doesn't happen in the future.  I'd propose 
in the short term we ignore any tests that rely on KenLM.  

There's a few options we can look at in the long term:  

*  Figure out an acceptable way to grab the KenLM binaries as a dependency when 
our project is built.  This would mean downloading them from a reliable source, 
and ensuring the binaries match our platform.
*  Download KenLM source as a dependency and build it locally when Joshua 
builds (but don't include KenLM source in our repository).
*  I was going to look into the feasibility of mocking out the language model 
for these tests.  I'm skeptical that this will work as there's likely millions 
of calls that would need to be mocked, even in the case of a small integration 
test example.  That being said maybe we can perform some kind of simplification 
to allow the tests to be useful and still be mockable.  
*  Using a different, Java based LM for unit tests.  We could for example use 
BerkleyLM, or a very simple Java LM implementation.



> Cannot build Joshua master branch
> -
>
> Key: JOSHUA-279
> URL: https://issues.apache.org/jira/browse/JOSHUA-279
> Project: Joshua
>  Issue Type: Bug
>  Components: build, documentation, tests
>Reporter: Lewis John McGibbney
>Assignee: Lewis John McGibbney
>Priority: Blocker
> Fix For: 6.1
>
>
> Hi Folks,
> We need to be cautious of whatever is committed to master branch... the build 
> has been broken for quite some time and there are constant Javadoc issues 
> which make the build unstable as well.
> For example, when i make an attempt to build master branch we have failing 
> tests
> {code}
> lmcgibbn@LMC-032857 /usr/local/incubator-joshua(master) $ mvn clean install
> ...
> ---
>  T E S T S
> ---
> Running TestSuite
> tm_pt_0=-2.000 tm_glue_0=3.000 lm_0=-206.718 lm_0_oov=2.000 
> OOVPenalty=-200.000 | -198.000
> ERROR - * FATAL: Can't find libken.so (libken.dylib on OS X) in $JOSHUA/lib
> ERROR - *This probably means that the KenLM library didn't compile.
> ERROR - *Make sure that BOOST_ROOT is set to the root of your boost
> ERROR - *installation (it's not /opt/local/, the default), change to
> ERROR - *$JOSHUA, and type 'ant kenlm'. If problems persist, see the
> ERROR - *website (joshua-decoder.org).
> WARN - sentence 0 too long 401, truncating to length 200
> WARN - sentence 0 too long 401, truncating to length 200
> WARN - sentence 0 too long 401, truncating to length 200
> WARN - sentence 0 too long 401, truncating to length 200
> WARN - no grammars supplied!  Supplying dummy glue grammar.
> WARN - no grammars supplied!  Supplying dummy glue grammar.
> WARN - no grammars supplied!  Supplying dummy glue grammar.
> WARN - no grammars supplied!  Supplying dummy glue grammar.
> WARN - no grammars supplied!  Supplying dummy glue grammar.
> WARN - no grammars supplied!  Supplying dummy glue grammar.
> WARN - no grammars supplied!  Supplying dummy glue grammar.
> WARN - no grammars supplied!  Supplying dummy glue grammar.
> %
> %
> %
> %
> %
> %
> %
> %
> %
> Tests run: 126, Failures: 1, Errors: 0, Skipped: 6, Time elapsed: 1.818 sec 
> <<< FAILURE! - in TestSuite
> setUp(org.apache.joshua.decoder.ff.lm.class_lm.ClassBasedLanguageModelTest)  
> Time elapsed: 0.075 sec  <<< FAILURE!
> java.lang.ExceptionInInitializerError
>   at 
> org.apache.joshua.decoder.ff.lm.class_lm.ClassBasedLanguageModelTest.setUp(ClassBasedLanguageModelTest.java:52)
> Caused by: java.lang.RuntimeException: java.lang.UnsatisfiedLinkError: no ken 
> in java.library.path
>   at 
> org.apache.joshua.decoder.ff.lm.class_lm.ClassBasedLanguageModelTest.setUp(ClassBasedLanguageModelTest.java:52)
> Caused by: java.lang.UnsatisfiedLinkError: no ken in java.library.path
>   at 
> org.apache.joshua.decoder.ff.lm.class_lm.ClassBasedLanguageModelTest.setUp(ClassBasedLanguageModelTest.java:52)
> Results :
> Failed tests:
> org.apache.joshua.decoder.ff.lm.class_lm.ClassBasedLanguageModelTest.setUp(org.apache.joshua.decoder.ff.lm.class_lm.ClassBasedLanguageModelTest)
>   Run 1: ClassBasedLanguageModelTest.setUp:52 » ExceptionInInitializer
>   Run 2: PASS
> Tests run: 124, Failures: 1, Errors: 0, Skipped: 4
> [INFO] 
> 
> [INFO] BUILD FAILURE
> {code}
> As a workaround I thought I will try to build the project without running the 
>