[jira] [Created] (JOSHUA-282) %S output format doesn't remove

[Matt Post (JIRA)]

Matt Post created JOSHUA-282:


 Summary: %S output format doesn't remove 
 Key: JOSHUA-282
 URL: https://issues.apache.org/jira/browse/JOSHUA-282
 Project: Joshua
  Issue Type: New Feature
Reporter: Matt Post
Assignee: Matt Post
 Fix For: 6.1


Using -output-format %S with the phrase-based decoder prevents removal of the 
 and  tags.



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

Re: Avoiding master failures with CI

[Matt Post]

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) 
>  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.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/15/16, 2:05 PM, "Matt Post"  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 
>>>  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 

Helping Spread the Word about Apachecon EU 2016

[Sharan Foga]

Hi Everyone

I'm forwarding the following message on behalf of Rich Bowen and the 
Apachecon team
==

As you are aware, we are holding ApacheCon in Seville in November. While this 
seems like a long way away, it is critical that we get on people's calendar 
now, so that they can plan, get budget approval, and spread the word to their 
contacts.

Here's how you can help.

If you Tweet, please consider using some of the following sample tweets to get 
the word out:


Save the date. #ApacheCon is coming to Seville, November 14-18 2016. 
http://apachecon.com/

Come join me at @ApacheCon in Seville in November. http://apachecon.com/

#ApacheBigData is the best place to learn what's next in the world of big data. 
November 14-16 in Seville http://apachecon.com/

 @TheASF is 300 projects strong and growing. Come learn about all of them at 
@ApacheCon in Seville - http://apachecon.com/


Follow @ApacheCon and @TheASF, and retweet mentions of ApacheCon, to spread the 
word. 


If you use other social media platforms, share the URLs of the events and their 
CFPs, to collect the broadest possible audience for our events, as well as 
getting the best content:


Big Data: Website: 
http://events.linuxfoundation.org/events/apache-big-data-europe
CFP: http://events.linuxfoundation.org/events/apache-big-data-europe/program/cfp


ApacheCon: Website: http://events.linuxfoundation.org/events/apachecon-europe
CFP: http://events.linuxfoundation.org/events/apachecon-europe/program/cfp


And, finally, if your employer benefits from the work that we do at Apache, or 
is looking for the brightest software developers in the industry, encourage 
them to sponsor the event. Sponsorship is available at all levels. Have them 
contact me at e...@apache.org for a prospectus, and I'll make the right 
introductions. Sponsors in the past include … well, everyone. You have to go 
pretty deep into the Forbes Technology list ( 
http://fortune.com/2015/06/13/fortune-500-tech/ ) to find a company that hasn't 
sponsored ApacheCon.

==

Thanks
Sharan