- Warn contributors that they need to register their email address in
their Gerrit profile. Not doing so causes errors at patch submission
and is a recurrent question on the mailing list.
- Add some links where useful.
- Remove confusing CGit link to TF-A source code. In the context of
setting up a local copy of the repo for contributing patches,
developers should rather clone it through Gerrit and this is best
covered by the "Getting the TF-A Source" section of TF-A
documentation.
- Add references to the OpenCI documentation, which has a lot more
details on some of the topics we briefly cover in the contribution
guidelines.
- Encourage the user to use the 'git review' command for patch
submission, inline with OpenCI documentation instructions. This
automatically sorts out which Gerrit server to push to and against
which repo branch (thanks to the '.gitreview' configuration file in
TF-A root directory).
- Elaborate the Coverity Scan section.
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
Change-Id: I1131662d8bc3502967b269a599869ea130897efb
With the transition to mailman3, the URLs of TF-A and TF-A Tests
mailing lists have changed. However, we still refer to the old
location, which are now dead links.
Update all relevant links throughout the documentation.
There is one link referring to a specific thread on the TF-A mailing
list in the SPM documentation, for which I had to make a guess as to
what's the equivalent mailman3 URL. The old URL scheme indicates that
the thread dates from February 2020 but beyond that, I could not make
sense of the thread id within the old URL so I picked the most likely
match amongst the 3 emails posted on the subject in this time period.
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
Reported-by: Kuohong Wang <kuohong.wang@mediatek.com>
Change-Id: I83f4843afd1dd46f885df225931d8458152dbb58
Added a couple of sub-sections (Coverity Scan and Test Configuration)
under "Add build configuration" to update the patch owners on the
sections they need to be aware of while introducing new source files.
Signed-off-by: Jayanth Dodderi Chidanand <jayanthdodderi.chidanand@arm.com>
Change-Id: I84adb182f9633863aac864df43578249c2269c1e
This change adds a new documentation page describing the commit style,
acceptable Conventional Commits types and scopes, and documents the
process for expanding the list of scopes.
Change-Id: Iad957b67fa71a879e8aa0790c58a5b08cec300d6
Signed-off-by: Chris Kay <chris.kay@arm.com>
This patch will fix the formatting errors concerning code snippet,
lines 245 and 256 respectively.
The code snippet is updated to 'shell' to lex it appropriately.
Signed-off-by: Jayanth Dodderi Chidanand <jayanthdodderi.chidanand@arm.com>
Change-Id: I53aefd81da350b6511e7a97b5fee7b0d6f9dde2d
Added a sub-section in the "Processes and Policies" chapter under
Contributor's guide on how to add new build configurations when new
source files are added to the TF-A repository. This will help the patch
contributor to update their files to get analysed by Coverity Scan.
Signed-off-by: Jayanth Dodderi Chidanand <jayanthdodderi.chidanand@arm.com>
Change-Id: I71f410a061028f89bd0e984e48e61e5935616d71
This change adds a configuration for commitlint - a tool designed to
enforce a particular commit message style - and run it as part of Git's
commit-msg hook. This validates commits immediately after the editor has
been exited, and the configuration is derived from the configuration we
provide to Commitizen.
While the configuration provided suggests a maximum header and body
length, neither of these are hard errors. This is to accommodate the
occasional commit where it may be difficult or impossible to comply
with the length requirements (for example, with a particularly long
scope, or a long URL in the message body).
Change-Id: Ib5e90472fd1f1da9c2bff47703c9682232ee5679
Signed-off-by: Chris Kay <chris.kay@arm.com>
Document the code review process in TF-A.
Specifically:
* Give an overview of code review and best practices.
* Give guidelines for the participants in code review.
* Outline responsibilities of each type of participant.
* Explain the Gerrit labels used in the review process.
Change-Id: I519ca4b2859601a7b897706e310f149a0c92e390
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
Signed-off-by: David Horstmann <david.horstmann@arm.com>
- Add some guidance about the type of information a patch author should
provide to facilitate the review (and for future reference).
- Make a number of implicit expectations explicit:
- Every patch must compile.
- All CI tests must pass.
- Mention that the patch author is expected to add reviewers and explain
how to choose them.
- Explain the patch submission rules in terms of Gerrit labels.
Also do some cosmetic changes, like adding empty lines, shuffling some
paragraphs around.
Change-Id: I6dac486684310b5a35aac7353e10fe5474a81ec5
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
Ensuring that each file changed by a patch has the correct copyright and
license information does not only apply to documentation files but to
all files within the source tree.
Move the guidance for copyright and license headers out of the paragraph
about updating the documentation to avoid any confusion.
Also do some cosmetic changes (adding empty lines, fitting in longer
lines in the 80-column limit, ...) to improve the readability of the RST
file.
Change-Id: I241a2089ca9db70f5a9f26b7070b947674b43265
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
We have noticed that Phabricator (the ticketing system on tf.org [1])
has far less visibility within the community than the mailing list [2].
For this reason, let's drop usage of Phabricator for anything else than
bug reports. For the rest, advise contributors to start a discussion on
the mailing list, where they are more likely to get feedback.
[1] https://developer.trustedfirmware.org/project/board/1/
[2] https://lists.trustedfirmware.org/mailman/listinfo/tf-a
Change-Id: I7d2d3d305ad0a0f8aacc2a2f25eb5ff429853a3f
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
This patch expands the coding style documentation, splitting it
into two documents: the core style rules and extended guidelines.
Note that it does not redefine or change the coding style (aside
from section 4.6.2) - generally, it is only documenting the
existing style in more detail.
The aim is for the coding style to be more readable and, in turn,
for it to be followed by more people. We can use this as a more
concrete reference when discussing the accepted style with external
contributors.
Change-Id: I87405ace9a879d7f81e6b0b91b93ca69535e50ff
Signed-off-by: Paul Beesley <paul.beesley@arm.com>
Signed-off-by: Petre-Ionut Tudor <petre-ionut.tudor@arm.com>
The User Guide document has grown organically over time and
now covers a wide range of topics, making it difficult to
skim read and extract information from. Currently, it covers
these topics and maybe a couple more:
- Requirements (hardware, tools, libs)
- Checking out the repo
- Basic build instructions
- A comprehensive list of build flags
- FIP packaging
- Building specifically for Juno
- Firmware update images
- EL3 payloads
- Preloaded BL33 boot flow
- Running on FVPs
- Running on Juno
I have separated these out into a few groups that become new
documents. Broadly speaking, build instructions for the tools,
for TF-A generally, and for specific scenarios are separated.
Content relating to specific platforms (Juno and the FVPs are
Arm-specific platforms, essentially) has been moved into the
documentation that is specific to those platforms, under
docs/plat/arm.
Change-Id: Ica87c52d8cd4f577332be0b0738998ea3ba3bbec
Signed-off-by: Paul Beesley <paul.beesley@arm.com>
Currently links between documents are using the format:
<path/to/><filename>.rst
This was required for services like GitHub because they render each
document in isolation - linking to another document is like linking
to any other file, just provide the full path.
However, with the new approach, the .rst files are only the raw
source for the documents. Once the documents have been rendered
the output is now in another format (HTML in our case) and so,
when linking to another document, the link must point to the
rendered version and not the .rst file.
The RST spec provides a few methods for linking between content.
The parent of this patch enabled the automatic creation of anchors
for document titles - we will use these anchors as the targets for
our links. Additional anchors can be added by hand if needed, on
section and sub-section titles, for example.
An example of this new format, for a document with the title
"Firmware Design" is :ref:`Firmware Design`.
One big advantage of this is that anchors are not dependent on
paths. We can then move documents around, even between directories,
without breaking any links between documents. Links will need to be
updated only if the title of a document changes.
Change-Id: I9e2340a61dd424cbd8fd1ecc2dc166f460d81703
Signed-off-by: Paul Beesley <paul.beesley@arm.com>
This patch attempts to standardise the document titles as well as
adding titles to documents that were missing one. The aim is to
remove needless references to "TF-A" or "Trusted Firmware" in the
title of every document and to make sure that the title matches
with the document content.
Change-Id: I9b93ccf43b5d57e8dc793a5311b8ed7c4dd245cc
Signed-off-by: Paul Beesley <paul.beesley@arm.com>
This change creates the following directories under docs/
in order to provide a grouping for the content:
- components
- design
- getting_started
- perf
- process
In each of these directories an index.rst file is created
and this serves as an index / landing page for each of the
groups when the pages are compiled. Proper layout of the
top-level table of contents relies on this directory/index
structure.
Without this patch it is possible to build the documents
correctly with Sphinx but the output looks messy because
there is no overall hierarchy.
Change-Id: I3c9f4443ec98571a56a6edf775f2c8d74d7f429f
Signed-off-by: Paul Beesley <paul.beesley@arm.com>
