CodeDevelopment

Introduction

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

• 13265 Andrei's recent talk
• 7591 Rob's offline work list
• 6240 Ray's older talk
• 6077 Rob's comments
• 6053 Andrei's older talk
• 5741 Andrei's older talk

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. minor - 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. major - 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 code releases, build trigger code.

In my opinion, the system should serve the first 3 primarily, under the assumption that the others are done less often and are done by people who are less likely to make mistakes.

Some Issues

• is it amenable to a tutorial?
• how will it run on OSG without /mu2e/app?
• will there be a different build time vs run time environment?
• is initial setup different from re-setup?
• what windows does the user have open? How does one know what a window is good for?
• what are likely points of confusion?
• is the directory structure organized and intuitive? Is offline separate from user code?
• is it fast and easy for an analyzer or junior to start a new project?
• what does a user type most often? Can it be shorter and simpler?
• can all dependencies be checked automatically?
• what does switching between prof and debug look like?
• how does an analyzer switch between pre-built releases?
• what build commands are supported for user code, how much are they forced to be coordinated with offline?
• are there clear lines of code responsibility?
• who coordinates pieces and tags and validates the whole (and how)?
• does it support code reviews and pull requests?
• does it support out-of-source builds?
• what parts of the dependencies are tagged and which are outside the tag?
• what do paths look like? do they include "mu2e"?
• what does validation do - continuous and nightly?
• what is the maintenance effort required?
• does it follow KISS?
• is it staged? does it fit into a long-term plan?
• is there a transition plan? How disruptive is it?
• does a major change like introducing the calibration database cause unnecessary disruption?
• is git history preserved?
• have we considered the best ways to speed up compilation?
• split out fcl partially or fully?
• split out Analysis package?
• consider separating sim and reco more sharply