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 <[email protected]> > wrote: > > Would everyone be ok with tomorrow at 5PM UTC? > > -Kellen > > On Tue, Jul 12, 2016 at 8:35 PM, Matt Post <[email protected]> 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 < >> [email protected]> 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) < >>> [email protected]> 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: [email protected] >>>> 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" <[email protected]> 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 < >>>> [email protected]> wrote: >>>>>> >>>>>> We've made a lot of progress on moving the project over to Apache + >>>> Maven. >>>>>> I was wondering if now would be a good time to consider re-thinking >> how >>>> we >>>>>> merge changes into master. The main goal would be to make sure we >> have >>>> a >>>>>> stable master branch that everyone can pull from. >>>>>> >>>>>> What I'd suggest is that we only merge into master once CI has >> completed >>>>>> testing. This way we can codify style rules, best practices, and make >>>> sure >>>>>> builds succeed and tests pass. We can develop new features create PRs >>>> as >>>>>> normal, and then get quick feedback if those PRs are mergable. I'd >> also >>>>>> suggest we dis-allow manual pushing to the master branch. >>>>>> >>>>>> I'm not sure how much effort this would be with the existing CI >> server, >>>> but >>>>>> I could investigate this if someone could grant me admin permissions. >>>> If >>>>>> it's a Jenkins server I'm sure it's possible. >>>>>> >>>>>> Another option is to use Travis CI. I have taken a quick look at >>>> Travis CI >>>>>> and it seems like a quite polished solution. It's free to use for >> open >>>>>> source projects. It supports automatically building + testing PRs. >> The >>>>>> interface is really clean. It has email notifications and group >>>>>> administration support. It's got support for multiple (programming) >>>>>> languages so we could in theory build kenlm as a build step and run >>>> those >>>>>> tests. >>>>>> >>>>>> Here's some more info on what the workflow with Travis-CI and PRs >> would >>>> be >>>>>> https://docs.travis-ci.com/user/pull-requests >>>>>> >>>>>> What do you guys think? Is there a strong preference for using >> Jenkins >>>>>> from the Apache community? Would everyone be ok with avoiding direct >>>>>> pushes to master? >>>>>> >>>>>> -Kellen >>>>> >>>> >> >>
