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 > >>> > >> > >
