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 <[email protected]> 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 <[email protected]> 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 < > [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 > >>>>>> > >>>>> > >>> > >>> > > > >
