Home

Table of Contents

• QMCPACK Development Policies
• Develop a new feature and integrate it back into the main public repository
• Create a private copy of the QMCPACK repository on Github
• Developers handling pull request code reviews
• Maintainers handling pull request submissions and merging
• Helpful git/Github configuration for developers
• Using the 'git flow' git extensions

Conventions used in this documentation

• To describe the location of branches, we use the abbreviation machine:gituser:repo:branchname. Obviously, this is not git command syntax. Here are some examples:
  • local:alice:qmcpack:newfeature (alice's "newfeature" branch in a "qmcpack" respository that is local to the repo cloned on her laptop/desktop, titan account home area, etc.)
  • github:bob:qmcpack:issue27 (the bob user's "issue27" branch that resides in his "qmcpack" repo on github)
  • github:QMCPACK:qmcpack:* (all branches in the "QMCPACK" organization's "qmcpack" repository on github)
• Commands typed at the linux comman prompt will be in fixed-width font and start with '$'. Command representation follows the conventions of the git man pages: Optional arguments are enclosed in square brackets. User-supplied information is enclosed in angle brackets. An example ("branch" is a user-supplied branch name argument that is optional):
  • $ git checkout [<branch>]
• PR, PRs = "pull request," "pull requests"

Transition todo

• Documentation — github wiki and/or qmcpack manual
  • old wiki move - what to include?
• CI
  • infrastructure availability status (graham)
  • how to automate code formatting check/enforcing (graham)
    • based on style at https://sites.google.com/a/cmscc.org/qmcpack/developers-forum/coding-guides
    • checkout:
      • http://stackoverflow.com/questions/22866609/can-clang-format-tell-me-if-formatting-changes-are-necessary
      • http://www.labri.fr/perso/fleury/posts/programming/using-clang-tidy-and-clang-format.html
      • https://llvm.org/svn/llvm-project/cfe/trunk/tools/clang-format/git-clang-format
    • does the code contain the appropriate copyright information
  • update scripts for new CI infrastructure
  • remove svn specifics from testing infrastructure and code
  • partition tests into PR, nightly, weekly
  • how to deal with nightly/weakly failures/regressions? - maintainer triages and assigns to right person?
• SVN to git repo conversion
  • authors file / translation svn to github emails - "best effort" (mark)
  • archive old issues (mark)
  • move open issues (mark)
    • how to deal with comment chains? cut/paste into main body of corresponding issue on github. use github API?