Section 10 ‐ Development Workflow (Aperture Viewer Specifics) - ApertureViewer/Aperture-Opertations-Manual GitHub Wiki

The Aperture Viewer development workflow is designed to ensure code quality, maintainability, clear attribution, and efficient collaboration, building upon established open-source best practices while incorporating project-specific requirements.

• Codebase Origin: Aperture Viewer is an independent, open-source third-party viewer for Second Life and OpenSimulator. Its codebase is a fork derived from the publicly available open-source codebase of the Firestorm Viewer. The Firestorm Viewer project, in turn, is derived from the official Second Life Viewer, originally developed and open-sourced by Linden Lab. Aperture Viewer operates under the same GNU Lesser General Public License v2.1 (LGPL v2.1) as its upstream sources.
• Independent Project with a Distinct Focus: While sharing a common ancestry with Firestorm, Aperture Viewer is an entirely independent project with its own distinct vision, mission, and development priorities. Aperture's primary focus is on significantly pushing the boundaries of visual fidelity, providing advanced and exclusive tools for virtual photographers and videographers, and refining the user experience for creative workflows. This often leads to different feature sets, UI designs, and default configurations compared to Firestorm.
• Policy on Code Contributions to Upstream Projects:
  • Aperture-Specific Features & Exclusivity: The vast majority of new features developed for Aperture Viewer (e.g., the Aperture Phototools Suite (Alt+P), the real-time Post-Processing Pipeline, the Procedural Starfield, unique UI themes, specific granular controls) are designed to be exclusive to Aperture and align with its unique vision of pushing visual fidelity and creator tools. These features represent Aperture's core differentiators and are often deeply integrated into its specific architectural modifications. They are fundamental to Aperture's identity and are generally not submitted to any upstream project.
  • Contributions to Linden Lab (Official Second Life Viewer):
    • Aperture Viewer's development is primarily focused on its own unique feature set. However, the project is open to selectively contributing well-developed, mature, and broadly applicable code to Linden Lab for potential inclusion in the official Second Life Viewer. This is done only when the work is deemed ready for wider application, would benefit all Second Life users, is fully code-ready, and aligns with Linden Lab's objectives.
    • Scope of Potential Contributions: Such contributions might include general bug fixes identified within the shared codebase that have broad impact, or potentially more significant, self-contained visual system enhancements or features (such as elements of the Aperture Phototools Suite or foundational rendering improvements) that have proven stable and beneficial within Aperture and are suitable for the core viewer.
    • Prerequisites for Consideration: Any potential contribution to Linden Lab must meet stringent criteria:
      • Broad Applicability & User Benefit: The feature or fix must be clearly beneficial to a wide range of Second Life users.
      • Maturity and Stability: The code must be thoroughly tested, stable, and "code ready."
      • Alignment with Linden Lab's Roadmap: The contribution should align with Linden Lab's technical direction and priorities.
      • Maintainability and Integration: The code must be well-documented, self-contained where possible, and straightforward for Linden Lab to integrate and maintain without imposing Aperture-specific architectures or extensive dependencies not desired by LL.
    • Process: Decisions to propose a contribution to Linden Lab are made by the Project Lead (William Weaver). Proposals are advanced through direct communication with Linden Lab, adhering to their processes. If interest is confirmed, a Pull Request would be meticulously prepared according to Linden Lab's contribution guidelines.
• Maintaining Upstream Sync: Aperture Viewer periodically merges updates from the Firestorm Viewer dev branch (and by extension, from Linden Lab's releases) into its own codebase. This is done to incorporate general bug fixes, security updates, new core features from Second Life, and to maintain compatibility with the evolving virtual world platforms. The process of merging upstream changes requires careful integration and testing to resolve conflicts with Aperture-specific modifications.

The primary technical stack for Aperture Viewer development includes:

• Primary Programming Language: C++
• Shaders: OpenGL Shading Language (GLSL)
• Build System: CMake
• Core Graphics API: OpenGL
• Key Libraries (Inherited & Utilized): FMOD (audio), Havok (physics - via Second Life), KDU (JPEG2000), CEF (Chromium Embedded Framework for web content), Boost, and numerous other open-source libraries common to Second Life viewer development.

Please refer to Appendix [L] for the full, detailed Git Branching Strategy.

Please refer to Appendix [M] for the full, detailed GitHub Issue Management process.

All code contributions to Aperture Viewer, whether from internal team members (other than the Project Lead who commits directly to dev) or external contributors, must be submitted via GitHub Pull Requests (PRs) targeting the dev branch of the official ApertureViewer/Aperture-Viewer repository.

The detailed process, including prerequisites, forking/cloning, branch creation from dev, making changes, local testing, and the specific requirements for PR titles, descriptions, testing information, and adherence to coding/commit guidelines, is documented comprehensively on the Aperture Viewer Wiki:

• Primary Guide: Contributing Code to Aperture Viewer (Wiki Page) (Replace Link-To-Contributing-Code-Wiki-Page with the actual URL when available)

Key aspects of the PR process include:

• PRs must be based on feature/* or fix/* branches created from the latest upstream/dev.
• PRs must have clear titles and detailed descriptions explaining the "what" and "why" of the changes.
• PRs must include specific testing steps performed by the contributor and instructions for reviewers/QA.
• All commits within the PR must strictly adhere to the Commit Message Guidelines (see Section 10.8 and Appendix [O]).
• All code must adhere to the Coding Conventions, including Aperture-specific commenting (see Section 10.7 and Appendix [N]).
• PRs should ideally address a single issue or feature.

All Pull Requests submitted to Aperture Viewer undergo a review process before being considered for merging into the dev branch. This process is crucial for maintaining code quality, stability, and consistency.

• Reviewer(s):
  • Currently, all code reviews are conducted by the Project Lead (William Weaver).
  • As the team grows, other experienced developers within the team may be designated as reviewers for specific areas or PRs, under the Project Lead's oversight.
• Review Focus: Reviews will assess the PR against the following criteria:
  • Functionality: Does the code work as intended and achieve its stated purpose? Does it correctly address the linked issue or implement the proposed feature?
  • Correctness: Is the code logically sound? Are there any potential bugs, race conditions, memory leaks, or other errors?
  • Adherence to Project Guidelines:
    • Does the code follow Aperture's Coding Conventions (Section 10.7, Appendix [N]), particularly the mandatory Aperture Commenting Style?
    • Do all commit messages within the PR strictly adhere to the Commit Message Guidelines (Section 10.8, Appendix [O])?
    • Does the PR itself (title, description, testing information) meet the submission guidelines (Section 10.5 and the "Contributing Code" Wiki page)?
  • Impact on Performance: Does the change introduce any significant performance regressions? If it's a performance-enhancing change, is the improvement demonstrable?
  • Impact on Visual Fidelity: For visual features, does the change improve or maintain visual quality? Does it introduce any visual artifacts?
  • Maintainability and Readability: Is the code well-organized, clearly written, and adequately commented (beyond the mandatory Aperture tags) for future understanding and maintenance?
  • Architectural Alignment: Does the change fit well within the existing architecture of Aperture Viewer? Does it introduce unnecessary complexity or dependencies?
  • Security: Does the change introduce any potential security vulnerabilities?
  • Testing: Has the contributor provided adequate testing information? Can the reviewer successfully test the changes based on the information provided?
• Review Process:
  • The reviewer will examine the code changes ("diffs") and the PR description.
  • The reviewer will attempt to build and test the PR branch locally.
  • Feedback, questions, or requests for changes will be provided as comments on the GitHub PR. Contributors are expected to be responsive to this feedback.
  • Multiple review cycles may occur if changes are needed.
• Approval and Merge:
  • Once the reviewer is satisfied that the PR meets all criteria and is ready for integration, it will be approved.
  • Only the Project Lead (William Weaver) will merge approved PRs into the dev branch. This is a strict policy due to the legal requirements of managing committer access under the Linden Lab Contributor Agreement. No other team member, regardless of role, will be granted direct commit access to the primary development branches of the official repository.
• Quality Assurance (QA) Involvement:
  • The Head of Quality Assurance (Eira Juliesse) and the QA team will be notified of merged PRs, especially those introducing new features or significant changes.
  • The QA team will incorporate these changes into their testing plans for upcoming internal builds and release candidates, providing an additional layer of verification.

Contributors are encouraged to engage constructively during the review process. The goal is collaborative improvement to ensure Aperture Viewer remains a high-quality, innovative, and stable platform.

Please refer to Appendix [N] for the full, detailed Coding Conventions and Style Guide. (Note for AOM in Appendix N: For the Aperture Commenting Style // <AP:TAG> ... // </AP:TAG> and // <FS:TAG> ... // </FS:TAG>, contributors should use their own unique initials or GitHub username as their TAG. The Project Lead, William Weaver, uses WW.)

Please refer to Appendix [O] for the full, detailed Commit Message Guidelines.