Standardise Liberty project structure
User story: I am a software developer. I would like to create/lint-check a Liberty project, so that I can ensure it is usable by a new developer familiar with Liberty standards.
We use conventions to make it easier for Liberty contributors to switch between projects. Project structure and conventions should support:
- high-signal communication (and be shared between all projects)
- low-effort rebranding and packaging
- low-effort source-based installs, builds and deployments, including for new developers
- should not encroach on language or framework conventions
- embrace tools we use (e.g. GitLab Community Edition)
Current ad hoc standards
- All projects under the https://source.puri.sm/liberty group.
- Most projects are named ldh_CONCRETE_PURPOSE with an alternate "friendly" name with a ship-building theme
- Example: ldh_middleware, friendly name "Keel"
- Counter-example: Smilodon
- Other projects (mostly clients) are in subgroups.
- README.md are in CommonMark with various conventions for sections, links and expressing project info (copyright, license, etc)
ldh_middlewarefor an up-to-date example
- Language standards. Most projects follow the common standard for their language, e.g. PEP8 for Python.
- Packaging standards. Most projects follow the packaging standards for their target platform, e.g. Debian for ldh_middleware, Android for liberty-social-android.