RTEMS Documentation Project
RTEMS Software Engineering Handbook
5.0.0 (master)
1. Preface
2. Introduction to Pre-Qualification
3. RTEMS Stakeholders
3.1. Qualification - Stakeholder Involvement
4. Software Development Management
4.1. Software Development (Git Users)
4.1.1. Browse the Git Repository Online
4.1.2. Using the Git Repository
4.1.3. Making Changes
4.1.4. Working with Branches
4.1.5. Viewing Changes
4.1.6. Reverting Changes
4.1.7. git reset
4.1.8. git revert
4.1.9. Merging Changes
4.1.10. Rebasing
4.1.11. Accessing a developer’s repository
4.1.12. Creating a Patch
4.1.13. Submitting a Patch
4.1.14. Configuring git send-email to use Gmail
4.1.15. Sending Email
4.1.16. Troubleshooting
4.1.17. Manage Your Code
4.1.18. Private Servers
4.1.19. Learn more about Git
4.2. Software Development (Git Writers)
4.2.1. SSH Access
4.2.2. Personal Repository
4.2.3. Create a personal repository
4.2.3.1. Check your setup
4.2.3.2. Push commits to personal repo master from local master
4.2.3.3. Push a branch onto personal repo
4.2.3.4. Update from upstream master (RTEMS head)
4.2.4. GIT Push Configuration
4.2.5. Pull a Developer’s Repo
4.2.6. Committing
4.2.6.1. Ticket Updates
4.2.6.2. Commands
4.2.7. Pushing Multiple Commits
4.2.8. Ooops!
4.3. Coding Standards
4.3.1. Coding Conventions
4.3.1.1. Source Documentation
4.3.1.2. Licenses
4.3.1.3. Language and Compiler
4.3.1.4. Formatting
4.3.1.5. Readability
4.3.1.6. Robustness
4.3.1.7. Portability
4.3.1.8. Maintainability
4.3.1.9. Performance
4.3.1.10. Miscellaneous
4.3.1.11. Layering
4.3.1.12. Exceptions to the Rules
4.3.1.13. Tools
4.3.2. Eighty Character Line Limit
4.3.2.1. Breaking long lines
4.3.3. Deprectating Interfaces
4.3.4. Doxygen Recommendations for BSPs
4.3.4.1. BSP Basics
4.3.4.2. Common Features Found In BSPs
4.3.4.3. Shared Features
4.3.4.4. Rationale
4.3.4.5. The Structure of the bsps/ directory
4.3.4.6. Doxygen
4.3.4.7. Doxygen Basics
4.3.4.8. Doxygen Headers
4.3.4.9. The @defgroup Command
4.3.4.10. The @ingroup Command
4.3.4.11. The @brief Command
4.3.4.12. The Two Types of Doxygen Headers
4.3.4.13. Generating Documentation
4.3.4.14. Doxygen in bsps/
4.3.4.15. Group Naming Conventions
4.3.4.16. Where to place @defgroup
4.3.4.17. @defgroups for CPU Architectures and Shared Directories
4.3.4.18. @defgroups for BSPs
4.3.4.19. @defgroups for Everything Else
4.3.4.20. Look Common Features Implemented
4.3.4.21. Check out the Makefile
4.3.4.22. Start with a .h, and look for files that include it
4.3.4.23. Files with similar names
4.3.4.24. Where to place @ingroup
4.3.4.25. @ingroup in the first type of Doxygen Header
4.3.4.26. @ingroup in the second type of Doxygen Header
4.3.4.27. @ingroup for shared code
4.3.5. General Doxygen Recommentations
4.3.5.1. Doxygen Best Practices
4.3.5.2. Special Notes for Google Code-in Students
4.3.5.3. Header File Example
4.3.5.4. Header blocks
4.3.5.5. Header guard
4.3.5.6. Includes
4.3.5.7. Using @defgroup for group definitions
4.3.5.8. enum and struct
4.3.5.9. Using @name for organization
4.3.5.10. Declaring functions
4.3.5.11. Ending the file
4.3.5.12. Source File Example
4.3.5.13. Files
4.3.5.14. Functions
4.3.5.15. Doxyfile Hints
4.3.5.16. GCC Attributes
4.3.6. Boilerplate File Header
4.3.7. Generating a Tools Patch
4.3.8. Naming Rules
4.3.8.1. General Rules
4.4. Change Management
4.5. Issue Tracking
4.5.1. Filing a Change Request or Problem Report
4.6. Why Contribute?
4.6.1. Common Questions and Answers
5. Software Test Plan Assurance and Procedures
5.1. Testing and Coverage
5.1.1. Test Suites
5.1.1.1. Legacy Test Suites
5.1.2. RTEMS Tester
6. Software Release Management
6.1. Software Change Report Generation
6.2. Version Description Document (VDD) Generation
7. User’s Manuals
7.1. Documentation Style Guidelines
8. Licensing Requirements
9. Appendix: Core Qualification Artifacts/Documents
Index
RTEMS Software Engineering Handbook
Docs
»
6. Software Release Management
»
6.1. Software Change Report Generation
6.1. Software Change Report Generation
¶
TBD - What goes here?