CodeDevelopment

From Mu2eWiki
Revision as of 22:33, 26 December 2017 by Rlc (talk | contribs) (→‎Some Issues)
Jump to navigation Jump to search

Introduction

A page to write some principles and questions for code development.

Use Cases

Each level incorporates the levels above.

  1. user - setup pre-built code and run utilities and standard mu2e fcl. Example: compare filter rates by modifying fcl, make a gdml file, run tutorials. Needs simple and fool-proof procedures.
  2. analyzer - checkout, build user code against pre-built offline, commit changes. Example: user makes ntuples from personal code or Stntuple makes an ntuple. Needs user code well-incorporated with offline - possibly using the same build system, possibly coordinated directory structures and commands. Fool-proof user-to-offline dependencies.
  3. junior - make localized modifications to offline, test and commit them, as in specific product maintenance. Examples: fix a bug in an algorithm, add an accessor. Needs quick and reliable partial build of arbitrary pieces. Needs to catch dependency mistakes. Needs to switch quickly between prof and debug.
  4. senior - make larger and more widespread changes, test and commit them. Examples: modifying major include files, reco sequences, products. Probably needs full build of offline. Needs quick checkout and build.
  5. expert - infrequent complex development - move code between packages, build prototype products with offline, build trigger code.

Some Issues

  • is it amenable to a tutorial?
  • how will run on OSG without /mu2e/app?
  • should there be a different build time vs run time environment?
  • can all dependencies be checked automatically?
  • are there clear lines of code responsibility?
  • who coordinates pieces and tags and validates the whole (and how)?
  • is it amenable to code reviews and pull requests?
  • does it support out-of-source builds?
  • what does switching between prof and debug look like?
  • how does an analyzer switch between pre-built releases?
  • what do paths look like? do they include "mu2e"?
  • what build commands are supported for user code, how much are they forced to be coordinated with offline?
  • what does validation do - continuous and nightly
  • what is the maintenance effort required?
  • does it follow KISS?
  • does it fit into a long-term plan?
  • does a major change like introducing the calibration database cause unnecessary disruption?
  • is git history preserved?