Commit f84932fd authored by Gururaj Shetty's avatar Gururaj Shetty
Browse files

Headings changed to Title Case

All headings changed to title case to maintain consistency

Closes: https://booting.oniroproject.org/distro/docs/-/issues/94

Signed-off-by: Gururaj Shetty's avatarGururaj Shetty <gururaj.shetty@huawei.com>
parent d5a3f63d
......@@ -20,7 +20,7 @@ Read The Docs project. You can inspect the `latest` version
[online](https://docs.oniroproject.org/en/latest/) or download it as
[PDF](https://docs.oniroproject.org/_/downloads/en/latest/pdf/).
## Building the docs
## Building the Docs
As per the current implementation for satisfying aggregation of multiple
`sphinx` projects, the repository takes advantage of symlinks which assume a
......
......@@ -4,7 +4,7 @@
.. include:: definitions.rst
Building |main_project_name| documentation
Building |main_project_name| Documentation
##########################################
This topic outlines the standard way of generating the |main_project_name|
......@@ -43,7 +43,7 @@ packages pre-installed in your system:
* Make (to build the documentation using the provided Makefile)
Building the documentation
Building the Documentation
**************************
To generate a local copy of |main_project_name| documentation, perform the
......
......@@ -17,7 +17,7 @@ testing development on real devices, like operating system boot-loader and
kernel development, while sharing access to a project-specific software
infrastructure used in the public cloud.
How does the CI system work?
How does the CI System Work?
----------------------------
The system automatically performs a set of test jobs upon a new or
......
......@@ -4,7 +4,7 @@
.. include:: ../definitions.rst
Bug handling process
Bug Handling Process
####################
Overview
......@@ -15,7 +15,7 @@ applying the best industry practices in terms of development quality. However,
as in every software projects, bugs do happen. This process explains how we
handle bugs.
How to report a bug?
How to Report a Bug?
********************
If you think you have found a bug in our distribution, please file a bug report
......@@ -34,7 +34,7 @@ issue. Use the provided template:
Developers review the reported issues and perform triage (see below). When a fix
is available, the ticket is updated with the details of the solution.
Which modules do we support?
Which Modules do We Support?
****************************
We do support all layers included in our reference images and blueprints. It means
......@@ -42,7 +42,7 @@ we accept bug reports in those layers. If the issue affects the upstream part of
the layer, we are going to redirect the report to the upstream project and work
with upstream on a solution.
Bug triage
Bug Triage
**********
The bug triage is a process where developers asses the bug and set its
......@@ -79,13 +79,13 @@ The bug can originate in a package developed by the project, or from one we use
from an upstream source. The process of handling a bug report will change
between those two cases:
When the issue is in the code developed by the project
When the Issue is in the Code Developed by the Project
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
In the case where the bug originates in the code directly maintained by the
Project, the bug is handled directly in the bug tracker.
When the issue originates from upstream code
When the Issue Originates from Upstream Code
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
If the issue was identified in upstream code, we report an upstream issue in
......@@ -99,10 +99,10 @@ Please note also that we periodically update maintained packages from upstream
sources, regardless of the bugs filled in our system. Our goal is to update to
the latest stable version of the package.
Detailed workflow
Detailed Workflow
*****************
Bug sources
Bug Sources
^^^^^^^^^^^
Bugs might be reported by different sources, including Project's own findings
......@@ -112,7 +112,7 @@ Mattermost channels, discussion forums etc. Issues coming from different sources
are centralized in the bug tracker, which also provides an unified
identification of all issues.
Acknowledgement and bug triage
Acknowledgement and Bug Triage
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
After the bug is entered, a developer will perform triage. The process starts
......@@ -133,7 +133,7 @@ questions to the reporter) in three working days for critical bugs and seven day
for other bugs. In case of a critical bug, the person performing triage informs
the maintainers of the affected subsystem.
Prioritizing and fixing
Prioritizing and Fixing
^^^^^^^^^^^^^^^^^^^^^^^
Bugs with the severity attached enter the prioritization process. It includes a weekly
......
......@@ -4,7 +4,7 @@
.. include:: ../definitions.rst
Gitlab contributions
Gitlab Contributions
####################
.. contents::
......
......@@ -4,13 +4,13 @@
.. include:: ../definitions.rst
REUSE compliance
REUSE Compliance
################
.. contents::
:depth: 3
SPDX information and REUSE standard
SPDX Information and REUSE Standard
***********************************
All projects and files for an hosted project **MUST** be `REUSE <https://reuse.software/>`_
......@@ -29,7 +29,7 @@ Some files will make an exception to the above rules as described below:
* Files for which copyright is not claimed and for which this information was not trivial to fetch (for example backporting patches, importing build recipes etc. when upstream doesn't provide the SPDX information in the first place)
* license files (for example ``common-licenses`` in bitbake layers)
SPDX header example
SPDX Header Example
-------------------
Make sure all of your submitted new files have a licensing statement in the headers. Please make sure that the license for your file is consistent with the licensing choice at project level and that you select the correct SPDX identifier, as in the following example for Apache 2.0 license:
......@@ -42,7 +42,7 @@ Make sure all of your submitted new files have a licensing statement in the head
* SPDX-License-Identifier: Apache-2.0
*/
Substantial contributions
Substantial Contributions
-------------------------
Therefore, if your contribution is only a patch directly applied to an existing file, then you are not required to do anything. If your contribution is an entire new project, or a substantial, copyrighted contribution, you **MUST** make sure that you do that following the `IP Policy <https://booting.oniroproject.org/distro/governance/ip-policy>`_ and that you comply with REUSE standard to include the licensing information where they are required.
......@@ -6,7 +6,7 @@
.. _sec_upstream_contrib:
Contributing to projects not maintained by |main_project_name| team
Contributing to Projects not Maintained by |main_project_name| Team
###################################################################
.. _sec_upstream_contrib_overview:
......@@ -18,7 +18,7 @@ In order to comply with :ref:`Upstream first<sec-upstream>` rule and Open Source
.. _sec_upstream_contrib_signoff:
Signing off contribution
Signing-off Contribution
************************
All contributions must be signed off by the |main_project_name| developer using their email account associated with the copyright owner of the work (in most cases it will be the corporate email address). This does not apply if the upstream project policy says otherwise or signing off of the contribution is not possible due to upstream project's limitation. It is recommended to use corporate email address as a sender address in case of email communication.
......@@ -38,14 +38,14 @@ It is |main_project_name| developer's responsibility to check license compatibil
.. _sec_upstream_contrib_cla:
Contribution agreement
Contribution Agreement
**********************
In case the upstream project requires signing of contribution agreement of any kind, the |main_project_name| developer must review it carefully before submitting the contribution. In case of any doubt they must contact their manager or legal team for further guidance.
.. _sec_upstream_contrib_security:
Security-related contribution and sensitive data
Security-related Contribution and Sensitive Data
************************************************
It is the |main_project_name| developer's responsibility to verify the data they share with upstream counterpart to prevent leak of sensitive information.
......
......@@ -4,7 +4,7 @@
.. include:: ../definitions.rst
|main_project_name| vision and aims
|main_project_name| Vision and Aims
===================================
System Positioning
......
......@@ -27,7 +27,7 @@ Scope
**Release timeframe**: 2020/11/15 .. 2021/04/12
The objectives of the release
The Objectives of the Release
-----------------------------
The purpose of this release is to provide the European |main_project_name|
......@@ -38,7 +38,7 @@ which we can share the entire 2021 roadmap of the project.
More details on the |main_project_name| goals can be found in the
:doc:`/overview/oniroproject-vision` document.
The list of software features included
The List of Software Features Included
--------------------------------------
+------------------------------------------------------------------+--------------------------+
......@@ -77,7 +77,7 @@ The list of software features included
| Automated sphinx-based documentation pipeline | Documentation |
+------------------------------------------------------------------+--------------------------+
Supported hardware platforms
Supported Hardware Platforms
----------------------------
+--------------------------------------------------------------------------------------------------------------------------------------+---------------------+----------------------------------+
......@@ -93,7 +93,7 @@ Supported hardware platforms
+--------------------------------------------------------------------------------------------------------------------------------------+---------------------+----------------------------------+
Test report
Test Report
-----------
Not available for this release.
......@@ -114,14 +114,14 @@ repo tool. Entire workspace is archived into sources tarball and can be prepared
$ tar -xvf asos-0.1.0.tar.xz
$ cd asos-0.1.0
Known issues
Known Issues
------------
The Avenger96 target (stm32mp1-av96) does not ship with firmware files for Bluetooth,
Wifi and the image processor by default. We are working on a solution to re-distribute
them during the normal image builds for this board.
Source code available
Source Code Available
---------------------
Source code and GPG signatures:
......@@ -153,7 +153,7 @@ The release is signed with the key:
=lKOe
-----END PGP PUBLIC KEY BLOCK-----
Devops infrastructure
Devops Infrastructure
*********************
To learn more about our approach to CI (Continuous Integration) strategy used for this release, please see:
......
......@@ -19,7 +19,7 @@ protect deployed products, sometimes we need to delay releasing information
related to security issues, following the industry best practices. However, all
information about vulnerabilities is becoming publicly available at the end.
How to report a vulnerability?
How to Report a Vulnerability?
******************************
If you think you have found a security issue in our distribution, please contact
......@@ -83,7 +83,7 @@ information becomes available.
The SRT meets weekly on a status meeting and participates in the general
Bug triage/prioritization meeting.
Classification of issues
Classification of Issues
************************
Security issues are classified as high, medium, and low severity. As a rule of
......@@ -95,7 +95,7 @@ thumb, we map the Base CVSS score from v3.1 in the following way:
- 7.0 and above - high severity
When the issue is in the code maintained by the project
When the Issue is in the Code Maintained by the Project
*******************************************************
When the source code where the issue comes from is maintained by the Project,
......@@ -123,7 +123,7 @@ severity, the fix waits until the next regular bugfix release. In the case of a
critical issue, the security team together with the release team may decide in
distributing patches to the affected users.
Handling upstream security issues
Handling Upstream Security Issues
*********************************
If the issue was identified in upstream code, we do report an upstream security
......@@ -135,7 +135,7 @@ If the upstream project does not respond, or does respond very slowly, we may
decide to develop a patch on our own. In this case, the vulnerability is using
the process for issues where we are upstream.
Detailed workflow
Detailed Workflow
*****************
Our process contains four phases: monitoring, assessment, remedy, and
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment