Project Structure Guidelines
(red) Don't take this page as a guideline yet, it's just some random thoughts for the moment.
How to organise projects?
Several git repos per project OR several sub-projects?
- Keep issues separate (e.g. pcb revision, hdl versions)
- Is it possible to have several repo per project in OHR? -> not yet!
- Several wikis to edit -> how to minimise drawback?
- Different types of project (pcb+hdl+sw+pts, hdl only, pcb only, ...)
Proposed ohwr project structure:
- top/main project
- PCB project
- Gateware project (hdl)
- Software project (driver, lib, test prog)
- Test project (prod/functional tests), board specific part of PTS
- PTS project, test framework, common libraries/classes
- HDL cores
Proposed git submodules structure:
- pcb
- sw
- sw dependencies (e.g. carrier, fmc-bus, zio)
- hdl
- hdl dependencies (e.g. hdl cores)
- test
- pts framework, common lib
- sw (e.g. carrier driver)
Releases
- min/maj (v3.2) or date-based (v02.2014)
- wiki release pages
- templates
- md5sum of binaries
- changelog only in one place
- automate page creation (Would be nice to have)
- git tags
Binary files (.bin, .pdf, ...)
- only in "Files" section
Testing (production and functional)
- PTS (Production) -> also include functional tests?
- common part in it's own project, part specific to a board in a sub-project of the board
- Install script
git submodules
- avoid dependency on hdlmake in hdl projects
- more flexible
- better structured -> avoid copy of sources
- avoid huge & messy repo (c.f. PTS)
git repos
- no binaries or huge simulation files
- ONE person (maintainer) commits to master
- other developers commit to proposed_master
- see Repository-use |
non-ohwr projects (CERN specific)
-
git vs svn (git for dev, svn for releases?)
-
official/operational releases location
-
binary files location
-
wikis.cern.ch for doc and jira for issues?
Matthieu Cattin, Feb. 2014