1. Easy for our team to pick up & stick with
1.1. Small number of commands to remember
1.1.1. Same commands work at "project" and "top" levels
1.1.2. "help" command that works everywhere
1.2. Easy to apply to new projects
1.2.1. Minimal boilerplate per project
1.2.2. Zero arguments = "right thing by default"
1.3. Quick, helpful feedback when used "incorrectly"
1.4. Value for all parties
1.4.1. Value for command-line users
1.4.2. Value for Testers
1.4.2.1. Working CI builds!
1.4.3. Value for Eclipse users
1.4.3.1. Bootstrap sys.path for debugger usage
1.4.3.1.1. Simplifies dev box setup
1.4.3.1.2. Developers see same errors as CI
1.4.3.2. Tie-in with Eclipse's notion of "projects"?
1.4.4. Value for build master (Howard)
1.4.4.1. Kill Howard's need to "edit proc_mgr config"
1.4.4.1.1. "start/stop config" ships with app
1.4.4.1.2. Give Howard a way to AUDIT the distributed configs
1.4.5. Value for OPS
1.4.5.1. Kill Mark's need to "edit Nagios config"
1.4.5.1.1. "service check" definitions ship with the app
1.4.5.1.2. Give Mark a way to AUDIT the distributed test definitions
2. Support company growth
2.1. Will it still work when we have 100 developers on staff?
2.1.1. Eliminate human "single points of failure"
2.1.2. Aim for 10x growth
2.1.3. Don't over-engineer
2.2. Allow independent sub-teams
2.3. Enforce contracts between teams
2.4. Allow "build/test master" roles to be delegated
2.4.1. self-subscribe to test results (subsets)
2.4.2. Coverage reports
2.5. Fast feedback for everybody, in every role
2.6. Eliminate single points of failure
3. Runnable on any dev host
3.1. Trivial setup process: no manual config
3.1.1. Install daylife-vendor
3.1.1.1. All build dependencies (code) in daylife-vendor
3.1.2. "svn co trunk"
3.1.3. "make config"
3.1.3.1. Foreach project: config
3.2. Any developer can (re)build a deployable set of RPMs
3.3. No state in an external DB
3.3.1. "Usable on an airplane"
3.3.2. State in SVN
3.3.2.1. current release number
3.3.2.2. ???
3.3.2.3. SVN revision number
3.4. Small set of top-level tasks to use repeatedly
3.4.1. "make rpm"
3.4.1.1. Foreach: build + package
3.4.2. "make install"
3.4.2.1. Foreach: install into virtualenv
3.4.3. "make test"
3.4.3.1. Run tests against virtualenv
3.4.4. "make clean"
3.4.4.1. Wipe build/install artifacts
3.4.4.2. "realclean" wipes all artifacts
3.4.5. "make lint"
3.4.5.1. Static type analysis
3.4.5.2. Code style check
4. Pythonic, but not Python-exclusive
4.1. Build types
4.1.1. Pure Python
4.1.2. Python + C extensions
4.1.3. Java
4.1.4. Able to extend for new build types
4.2. "pythonic" = leverages Python skills
4.3. "pythonic" = looks like pseudocode
4.3.1. Minimal "stuff to remember"
4.3.2. Minimal "magic"
5. Support Continuous Integration
5.1. CI == fast feedback
5.2. Run test suite, starting with nothing more than an initial checkout
5.3. Wipe ALL artifacts, resetting to "virgin checkout" state
5.4. Install into an arbitrary root dir to allow > 1 CI build/box
5.4.1. trunk
5.4.2. other branches
5.5. Test output in standard formats
5.5.1. Unit tests -> JUnit XML
5.5.2. Style tests -> ??
5.5.3. Static type analysis -> ??
5.5.4. Coverage report -> Clover XML?