Don't ask about github pushing.... its like the antichrist! ;) --------------
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 <http://www.meteorite.bi/products/saiku/sponsorship>) On 15 July 2016 at 23:31, Mattmann, Chris A (3980) < [email protected]> 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: [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/15/16, 2:05 PM, "Matt Post" <[email protected]> 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 < > [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 > >>>> > >>> > > >
