Developer Working Group 2: Code Submission Guidelines

Developer Working Group 2: Code Submission Guidelines
Session Leader(s): Chris Barnett, Steve McDonald
Background & Agenda:
In order to work together effectively and produce a maintainable code base, we must make some decisions to establish the conventions and practices that we will use.

Areas for discussion:
1.    coding style and practice for JavaScript and Java
2.    practices and conventions for GitHub code submission

Below are links to Google docs providing some information on these topics.  The documents are not meant as proposed drafts, but merely as springboards for discussion.  Feel free to add comments and ideas.

The goal of the session is to provide a skeleton for a draft style guide by identifying areas of common agreement.  From there we can work towards resolving areas of disagreement.

If some areas require more exploration, additional action items may emerge.

Session notes:

Bess: Did this break anything, perhaps using unit test

Chris how do we get to unit tests

Steve: end to end tests too

Bess: experience on transitioning to multi-institution

Blacklight at UVa, unit test required for Stanford adoption

testing enables collaboration

all new code contributions require test coverage

    provide example of good tests

used RSpec, Hudson/Travis

test driven development tends to improve code quality/refactor since functions are designed to be testable

Chris: rules enforces better development practices

Darrin: javascript testing

Mike: problematic, given scale of our JS, we should try something

    Jasmine, but there are lots of frameworks

    how do you want to run tests: command line/Node.js or in browser

    Travis include node.js or phantom.js

    Functional testing is useful but unit testing tends to provide more actionable results



Mike will write up some JavaScript unit testing frameworks



Java: everybody like JUnit



use Travis, it connects well with GitHub and is free

Bess: first, check out, build and run tests, then change code and run tests, create pull request.  CI/Travis runs to double check

?: It makes it so much easier to add code because test

Bess: need recommendataion for unit testing

Mike : Manning book JUnit in Action,

GitHub policy

Mike: Simple branching is better

Master is latest stable code

Releases are tagged

Lots of forking

Mike: consider a master branch, a release branch that gets merged in

Releases are tags on the master branch

Maintenance branches are generated as needed

  •     The focus is on future development, not supporting old releases
  •     It isn’t merged back into master,
  •     Not a high priority

Bess: what is upgrade process

    especially when local customization is significant

Darren: a lot of the customization is in config files

Action items:

new code requires test code

start after the 2.0 commit?

everyone to peruse: Manning book JUnit in Action,

use Travis, it connects well with GitHub and is free

Mike will write up some JavaScript unit testing frameworks